iso work on Lisp

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

    To what extent can we consider the following to make EU happy?
      a) subsets of CommonLisp
      b) alternatives that are additive
      c) alternatives that can be made additive
        by loading a support file.

My own opinion, which I have expressed to Chailloux on several
occasions: 

I've never had any problem with some group going off and defining a
subset, or more than one, as long as they don't create too much
confusion about what the "real" Common Lisp is.  That means that if it
claims to be a subset, it must really be a subset and not some
incompatible simplification.  And that if a multiple-level standard is
created, the name "Common Lisp" is reserved for the language we
currently have; the others are Common Lisp "subsets" or "kernels" or
something like that, and not "Common Lisp, Level 1".  And even the
naming issue might be negotiable.

I personally think that making an official subset is a waste of time.
Any machine with virtual memory can easily support the full language,
and for delivery of critical applications on small machines, the subset
you want is whatever subset you happen to have used.  There are simple
GC techniques that flush most of the unused stuff once you're done with
development.  I think that if you do want a subset, you want a different
subset for each application: education, CAD, symbol-crunching, writing
editors, and so on.  But while I personally have no interest in subsets,
it does no harm if someone goes off and defines one, even if they
make it official.  So if that's all it would take to make them happy, I
have no objection.

Chailloux, in private discussions, has said he wants a compatible Common
Lisp subset, but Fitch, Padget, and Stoyan want to clean everything up.
They have stated at various times that Common Lisp should not be
standardized in its current state -- they use the word "standard" to
mean some Platonic ideal of the perfect Lisp.  So maybe we could entice
the INRIA people with this offer, but not the others.  Even if they
agreed that we get to do Common Lisp while they do subsets, there might
be problems with other groups interested in subsets, including Ida in
Japan, Gold Hill, and Kessler at Utah.  All have different ideas.

I have also said to Chailloux that if they have specific ideas for
changes, we would be happy to consider them, especially if they take the
form of compatible extensions.  That is not to say that we would accept
whatever changes that they propose -- no blank checks in this business.
But I don't think they're into extensions, from the technical material
I've seen so far.  They want to clean things up in fundamental ways and
make the whole language more Scheme-like, on the one hand, and to
preserve their existing investment in the code for LeLisp and Cambridge
Lisp on the other hand.  And they have this weird concern for what kind
of minimal Lisp can be done on a Z-80.  Why they didn't pick a PDP-8, I
don't know!

I don't want to fight with these people.  The split is partly our fault
for not having found some way of including them in the original design
discussions.  We should be as accommodating as possible, on all
dimensions, without taking the fatal step of allowing them to dictate
incompatible changes in the existing Common Lisp.  I'd really like to
bring the Eulisp people into the fold, but they're academics, and if
they want to be stubborn they don't have to pay attention to the rest of
the world or to the kinds of concerns that come up when you need to sell
a made-up standard to real companies with real users.  If they insist
upon being unreasonable and on trying to keep the current Common Lisp
out of ISO, we'll just have to fight it out.  They have about a dozen
people involved in Eulisp, more or less.  I'm happy to listen to their
ideas, but in a sane world there's no way they should be able to dictate
terms to 30 or so major companies hundreds of people involved in
implementation efforts, and a Common Lisp user community that already
numbers in the thousands and is growing fast.

-- Scott