[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: CL-Cleanup@SAIL.STANFORD.EDU
- Subject: Cleanup status
- From: Masinter.pa@Xerox.COM
- Date: 6 Jan 88 23:28 PST
OK, here's another try.
My recent message prompted enough debate that I thought I would clarify what I
meant in my recent message about FLET. Some assumptions:
X3J13 is attempting to define an ANSI standard for Common Lisp.
X3J13 is starting with "Common Lisp the Language" by Guy L. Steele, Jr. and
considering various clarifications, changes, additions, enhancements,
The "cleanup committee" of X3J13 is considering those minor clarifications,
changes, additions, enhancements, modifications as do not fit within the charter
of the other subcommittee's of X3J13 (namely objects, windows & graphics,
characters, iteration, compilation, validation, and possibly some others that I
The process for various cleanups is that we (the cleanup committee) consider
proposals either that we generate (e.g., based on Guy Steele's original list of
proposed modifications), that we get from the community, or are based on mail to
common-lisp@Sail.stanford.edu that seems to have reached some convergence.
We produce a writeup (similar to the one I mailed for FLET-IMPLICIT-BLOCK) for
consideration by X3J13. X3J13 then can vote on a ballot which essentially says
("we believe the ANSI standard for Common Lisp should reflect the following
The cleanup proposals, in their various draft forms, are a good indication of
those places where CLtL is ambiguous, lacking, or subject to change; those
cleanup proposals endorsed by X3J13 are a very good indication of what the ANSI
standard will look like. However, the result of the standard process will be a
single standard with (we hope) no options. An implementation will either conform
or it will not.
If implementors want our advice (unlikely as that might be), we'd advise them to
quickly adopt those proposals which resolve ambiguities in CLtL and (as
"Proposed Extensions likely to be in the Common Lisp standard") to implement
those proposals that are extensions.
However, we would advise implementors not to release (at least as "Common Lisp")
implementations with the proposals that are incompatible changes; to do
otherwise would increase the diversity of "Common Lisp" implementations for
users, rather than decrease it.
Most strongly, of course, we'd advise implementors to document their
implementation carefully in these areas, so that users might at least #+ and #-
around problem areas.
Part of the reason is that, even though the proposals have received endorsement
in isolation, they may be later superseded by other proposals or rescinded on
the basis of "new evidence".
What's it all mean to users of Common Lisp?
Well, of course, we hope the proposals themselves cntain useful information,
and explain why there was an issue at all, and the reasons for our choice.
If you have strong opinions about any of the proposals, make sure your X3J13
representative hears about them. If you would like some additional changes,
please give them to your X3J13 representative to submit.