[no subject]

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

Jerome, Gilles, and Bernard,

I apologize for the delay in answering your mail on Eulisp and Common
Lisp.  First your message to me had a bad address and had to be resent;
when it finally arrived, it did so in an unusually busy week.

First, let me agree with what Guy Steele has said: we certainly would
welcome the opportunity to cooperate with members of the Eulisp group.
Now that we seem to have established reliable netmail communication
across the Atlantic, that should be much easier; this was the main
barrier to seeking European participation back when the Common Lisp
effort started, five years ago.

You ask how stable or evolving the current Common Lisp definition is,
and how much outside input the "gang of five" is really willing to
accept.  Let me try to address that issue at some length, because it is
a crucial one.

One thing that has become clear to all of us in the five years we have
been working on Common Lisp is that it is MUCH easier to design and even
implement a clean, elegant Lisp specification than to get many diverse
projects to agree upon such a specification.  At the time we started the
Common Lisp design it was almost too late: a number of major Lisp
projects had already started down different paths, and some of them
already had sizable bodies of user-code and hundreds of users.  I'm
still amazed that we were able to pull this diverse community together
around a single standard.  In order to reach this agreement, we
sometimes had to make decisions based upon what already existed, rather
than always choosing the most elegant solution.  We made these
compromises because we all felt that having a single reasonably good
Lisp standard, supported by all manufacturers, was much more valuable
than having twenty different dialects, each of them beautiful.

Now we have the Steele book and all of the major U. S. manufacturers
have decided to support Common Lisp as defined in that book.  Many
implementations have already been done.  There is a growing body of user
code, several instructional books, and a lot of users.

This existing community wants us to develop a clear standard for the
language, to set up a formal mechanism for resolving ambiguities as they
arise, to create a validation suite, to discuss extensions in the areas
where Common Lisp is incomplete (such as the error system and support
for object-oriented programming), and to set up some mechanism for
sharing public-domain code.  They don't want to see any radical changes
in the language -- at least, not in the near future -- because they are
right now in the process of releasing their first implementations of
Common Lisp using the Steele book as a guide.

What this means is that the process of developing a standard for Common
Lisp must be a rather conservative one.  Incompatible changes can be
considered, but in evaluating each proposed change we must consider not
only the its merits but also its cost in terms of implementation effort,
changes to existing code, and re-training of users.  Clarifications,
extensions, and transparent changes are easy, as are proposals for
standardized subsets, but changes that go to the heart of the language
probably could not be adopted for this first round of standardization,
in 1987 or whenever.  More radical changes might be acceptable in a
later standard, perhaps for Common Lisp 1990.

Let me emphasize that this conservatism is not because we believe that
Common Lisp is perfect or because we want to keep total control of it;
it is just a question of what we believe that the Common Lisp community
wants and needs right now.  We are quite eager to get European
participation in this ongoing standardization effort, and we would like
to add some European members to the technical committee that will be
making these decisions for Common Lisp.  But it seems to me that this
only makes sense if the people involved share our desire to standardize
something that is not radically different (in an incompatible way) from
the existing Common Lisp.

We can certainly understand why someone might want to develop a new,
more elegant Lisp without all these pre-existing constraints.  I have
often felt the urge to do that myself.  Such a Lisp might be used in
education right away -- a role that Scheme seems to be filling in the
U.S.  It could also serve as a laboratory for the development of new
Lisp ideas, and eventually it might replace Common Lisp as the language
favored by industry.  If the EuLisp group chooses to work independently
on such a dialect, with Common Lisp serving only as a source of ideas, I
think that is a worthwhile thing to do.  If some members of this group
want to work on EuLisp and on standardizing Common Lisp as well, that is
good -- it will lead to better communication between the groups.  But it
is unreasonable to expect that the Common Lisp community will
automatically follow where you lead, whether or not you control ISO.

Let me also address the other points you raised:

You ask about the absence of a well-defined semantics for Common Lisp.
If by that you mean some sort of formal logical specification, I don't
believe that this technology is ready to handle something as complex as
Common Lisp.  Maybe I am wrong about that.  I would like to see such a
formal specification, but not if it means throwing side-effects and
things like Catch/Throw out of the language.

Common Lisp does indeed lack orthogonality and consistency in many
areas.  This is a result of the political process described earlier.
It is ugly, but not fatal.  Some of this can be cleaned up, but we must
move slowly and carefully.

My guess is that the first attempt to produce a Common Lisp standard
will include an error system, along the lines proposed by Kent Pitman,
and it may include an object oriented programming system along the lines
of CommonLoops.  If we cannot agree upon an object oriented system
quickly, this could be added later as a supplement to the standard.
Given the variety of hrdware and operating systems on which Common Lisp
runs, I see little prospect of standardizing on interactive interfaces,
windows, or graphics.  I think that we will see a few informal standards
emerge, one for time-sharing machines with character-oriented terminals,
one for high-resolution bit-mapped machines, etc.

We are trying to collect a validation suite at ISI, and to work out the
formal procedures for validation.  This is not going as quickly as I
would like, but I see no major problems in this area.

    - The current complexity of CL makes it doubtful that it can actually
    be used for the large scale production of industrial software in the
    framework of current software engineering technology, outside the
    closed world of Lisp hackers.  The Ada language has been heavily
    criticized on that basis, though it is much simpler and cleaner in
    design, and is a lot safer to use for the average programmer.

I disagree completely with this view.  Most of the complexity in Common
Lisp is due to the number of utilities that are built in.  It is the
equivalent of having a large external library of useful utilities in a
language like Ada.  This makes the language more useful for real work,
not less.  Of course, you do not try to teach a new user to use all of
these things at once; one needs tutorial materials that introduce the
failities in some reasonable order, a few at a time.

In any event, Common Lisp is already being used in industry for a number
of large-scale projects, and many people at CMU who were not Lisp users
in the past have begun to use it -- and to like it.  Now that the
language is available on conventional hardware, it is spreading very
fast.

    - we all share the same love for Lisp and we are here very afraid
    that a strong push such as yours with CL in its current state may in
    the long run have negative effects on Lisp itself, when large
    industrial projects find out that the language cannot be properly
    handled by standard programming teams. PL/1 or even Algol 68 (though
    nicely defined) did not survive, while Pascal (not a very good
    language, but simple) is doing rather well.

Again, I think that your fears are groundless.  Common Lisp is already
spreading very fast, and there seem to be no particular problems in
using it in large projects in industry.  We have also had good success
at CMU in teaching Common Lisp to undergraduates with no previous
programming experience.

I think we have the same goals, but a different perception.  We feel
that Common Lisp is imperfect, but good enough to serve as an important
vehicle for industrial AI and for most research; you feel that it cannot
succeed without many changes.  We feel that we must standardize on
approximately the present Common Lisp (with clarifications and some
extensions) or risk losing the agreement among manufacturers and
large-scale Lisp users that we have worked so hard to achieve; you feel
that we should change the language, radically if necessary, until it is
clean enough to appeal to the academic community.

I think that there is some room for compromise here, but only up to a
point.  If the goal of producing a single international Lisp standard
requires changes that threaten the unity of the existing Common Lisp
community, then we would have to give up that goal and follow our
separate paths.  Even then, I would hope that the two communities would
communicate and cooperate wherever possible.

Regards,
Scott Fahlman