[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Common Lisp 2000
- To: Jeff Dalton <enea!aiva.ed.ac.uk!jeff@SEISMO.CSS.GOV>
- Subject: Common Lisp 2000
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
- Date: Mon, 23 Jun 1986 20:04:00 -0000
- Cc: common-lisp@SU-AI.ARPA
- Sender: FAHLMAN@C.CS.CMU.EDU
How do people feel about making changes like immutable/mutable whatevers
part of the ANSI/ISO standard instead of waiting for Common Lisp 2000?
I don't mean this particular change, which after all we might decide we
don't want at all, but rather changes of this magnitude. The EuLisp
proposals for the ISO standard do contain suggestions on this scale.
I sent out a message a couple of weeks ago describing my own views on
what guidelines we should follow in developing a proposed ANSI/ISO
standard definition for Common Lisp. Basically, the view was that
Common Lisp is already a de facto standard with many implementaitons and
many users. Any tinkering we do on the way to making it an official
standard has to consider the costs of each change, in terms of existing
implementations, application code, user skills, and documents, as well
as any benefits the change might bring. I believe that the guidelines I
suggested accurately reflect the views of the overwhelming majority of
the Common Lisp community (there was only one dissenting message), and
unless that view is shown to be in error, I expect that the new Common
Lisp definition we are developing will follow them.
With Common Lisp we have achieved an important goal: unifying the
commercial part of the Lisp community behind a single dialect.
Developing an official standard for Common Lisp will help to cement that
goal, and will give the commercial world something stable and usable to
hang on to while work continues on better Lisps for the future.
All of us would like to see better, cleaner Lisp systems in use
eventually, and I applaud the efforts of the Eulisp people to develop a
more rational dialect of Lisp and to explore the potential for formal
methods in defining a system of this size. I see no conflict between
this work going forward and the adoption of a standard for Common Lisp.
In fact, if the competitive aspect were eliminated, I think that it
would be much easier for the EuLisp group to stick to their vision of
truth and beauty: no need to make the sorts of compromises that would be
required to win over companies in the short run. In addition, it would
make it easier for us to contribute ideas to the EuLisp development, and
for the EuLisp people to participate in our attempts to clarify Common
Lisp in minor ways.
The stumbling block, as I see it, is the insistence by some of the
Eulisp people that there must be only one Lisp standard in the
forseeable future, and that that place must be reserved for an
"acceptable" dialect, and not the one that everyone is using. The
commercial AI world has just, at great expense, settled on Common Lisp,
and they are not going to make any more radical changes in the next
couple of years, regardless of what we or EuLisp or ISO might do. In a
couple of years (sooner than the year 2000, I think), the industry might
be ready to shift to EuLisp or some version of Scheme or a version of
Common Lisp that is cleaned up in more radical ways. I'd like to see
that happen, when the time is right and when the new candidate has
established itself on its merits. It will happen sooner if we can give
the people in industry a period of relative stability by adopting Common
Lisp as a standard in the meantime.