Re: CLIM on CMU CL

[Mark A. Son-Bell <MAS-B@FUJI.ILA.COM>]

    Date: Sun, 19 Jan 92 18:36:51 EST
    From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


    Mark,

    Thanks for your note.  This is certainly an issue I would like to explore
    at some length, since we're currently trying to decide just what our
    graphical user-interface strategy should be for CMU Common Lisp.

    I think that if your goal is to make CLIM a widely accepted standard for
    Lisp based graphics, 
Close - our goal is to make CLIM the standard UI API for portable CL
applications.  If one is not interested in portability, then something
less generic than CLIM will always be more efficient (if perhaps less
powerful).
			 it is a very good move to make a public-domain version
    available.  As you know, we have been working pretty hard to make a decent
    public-domain Common Lisp available, and to us CLIM looks like a threat.
    If it catches on as a standard, and if it is too complex (or too
    well-protected legally) to be cloned, then we and our users are faced with
    a nasty set of alternatives:
	...
    Because of this, we and a lot of others have been hoping that CLIM would
    fail to become a widely-used standard, and we've been doing what we can to
    provide attractive alternatives.  This has nothing to do with the technical
    quality of CLIM -- in fact, I know very little about it -- but is just a
    result of its restricted availability.
Pardon my defensiveness, but we've never restricted the availability of
CLIM.  We can't give it away for free because (unlike PARC with PCL) we
don't have an infinite bank account to draw on, and there is a lot sunk
into CLIM that has to be recouped.  On the other hand, it has always
been the business objective to make CLIM a bundled part of "extended CL"
systems, commercial and public-domain.  (More on this below.)

    A public-domain CLIM would remove all of these problems, and let the system
    compete with the other alternatives on its technical merits.  What we need
    to explore is how this can be done without destroying your business.  
We don't think there's any risk of this.  I do accept the sentiment as a
sincere expression of concern, though, and thank you for it.
									  I
    don't know a lot about ILA, but my impression is that CLIM is your only
    major product and that your income is mostly in the form of license fees
    from Lucid, Franz, and other large vendors.  
(Actually, most of ILA's revenue comes from our natural language products
and consulting.)  The ongoing CLIM business does generate license fees,
royalties and product revenues (from our CLIM for MCL 2.0), but we don't
think that any of this would be diminished significantly by there being
a CLIM for CMU CL.  None of the main Unix CL vendors (Lucid, Franz, and
Harlequin) expresses any concern about competition from CMU CL.  Now, we
think that some of this is whistling past the graveyard, but that's
really their concern and not ours.
						 Would a public-domain CLIM
    destroy this, or enhance it by funneling more users into the system and
    creating a demand for more support and extensions?  
We think the latter.  The more CLIM is locked in as a standard for CL,
the greater will be demand for our services as the company that made
CLIM happen.  Moreover, there is a certain "for the common good" aspect
to this whole CLIM business in the first place.  When we started the
CLIM effort back in 1988 it was designed as much to do our bit to help
save CL as it was to make us rich - it was largely defensive.
							Would the big companies
    continue to deal with you, or would they just grab the public-domain
    version and run?  Or did you have in mind a public-domain version that is
    crippled in some way?
This is something to be discussed.  Our preference for the moment would
be to have the CLIM sources shipped with CMU CL be under a (free)
license that would prevent a user from recompiling or otherwise using
them with any other Lisp.  Alternatively, all the #+'s could be taken
out so that it would be very troublesome to port to Franz or Lucid or
Harlequin.  In the best of all possible worlds (drawing on the PCL and
CLOS precedent) your developer(s) would do a "native reimplementation"
from the portable reference implementation that we provide, so the
sources wouldn't be of much use on any other Lisp.

It's one thing to have CLIM on CMU CL be competitive, the way your PCL
and (soon) CLOS are (will be).  It's another to give away for free
sources that can just be recompiled into the EQ binaries that Lucid et
al are charging money for.  The problem really is that we (ILA and the
vendors who have helped underwrite CLIM) need to recoup the investment
that's gone into the development, or come up with a good case for simply
writing it off.  The same way many of the vendors were charging extra
for object systems (Flavors or PCL) for a while, we think the market
will bear an additional cost for the value that CLIM provides, which,
after all, we believe to be substantial.

    I would like to understand what your thinking is here and see if we can
    come up with a solution that will be beneficial for us, for you, and for
    the Lisp vendors.

    Once we understand what everyone is trying to achieve here, then we can
    begin to look at the more technical issues:

    1. We need to learn more about CLIM.  Could you send us a set of manuals?
    Three or four would be even better, if they're not huge, so that we can all
    learn about this in parallel.
You can access the postscript files of the TeX version of the CLIM 1.0
manuals via anonymous ftp on ila.com - there are two files which you can
fetch with "mget pub/clim1*".  What we really want to do, though, is get
your project going on CLIM Version 2, which is significantly different,
and not yet very well documented.  We'll have a preliminary spec coming
out pretty soon, but it'll probably take some hand-holding to get anyone
at your end up to speed within the next month or two.

    2. You have identified CLOS as a potential problem.  Are the problems with
    missing functionality, performance, or both?  
Both.  (I'll defer to Bill for more specifics.)  Suffice it to say that
we have managed to port various versions of CLIM to various versions of
PCL in the past, but that it was never easy.  Moreover, since all of the
Lisps that we were directly concerned with commercially had moved to
native CLOSes, we've dropped all/most of the old #+PCL's from our
sources, and these could be a bit of a pain to recover from the archived
sources.
						  Rob has already updated our
    system to use the latest version of PCL -- this will probably go into some
    near-future release.  His next major project is to do a native CLOS for CMU
    CL, tightly integrated with the Python compiler for best possible
    performance.  But this might take six months or more.  It's possible that
    we could fix specific performance problems sooner than that, once we know
    what is needed.

    3. I'm not sure what other problems we might have to fix -- we'll need to
    discuss that with you.  We've got CLX up, of course, and also a good
    call-out to C code.  What other non-standard facilities are needed?
None.  The call-out to C could be useful, depending on the back-end
connection strategy we use.  For example, under Lucid, version 2.0 will
be connected up to Open Windows via LispView (at least initially), but
that back-end won't be portable since LispView uses Lucid's FFI.
There's also a lot of work going on in various shops to bypass CLX and
call straight into the C X library and toolkit.  But with regard to
porting CLIM to CMU CL, that's really all futures - there will be plenty
of work in just bringing up the existing body of software, including the
existing CLX back-end.

    Cheers,
    Scott Fahlman

    P.S. I'm not sure exactly who I am talking to here.  What is your position
    in ILA, and who is "york"?
I'm the president, and Bill York is the main CLIM architect and head of
ILA's CLIM activities (as well as a principal and director).

Regards,

Mark Son-Bell