[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: LISP-PACKAGE-NAME (Version 1)
- To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: Issue: LISP-PACKAGE-NAME (Version 1)
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Thu, 22 Dec 88 15:35:09 CST
- Cc: CL-Cleanup@SAIL.Stanford.EDU, X3J13@DSG.csc.ti.com
- In-reply-to: Msg of Thu, 22 Dec 88 14:03 EST from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Sender: GRAY@Kelvin.csc.ti.com
> Proposal (LISP-PACKAGE-NAME:COMMON-LISP):
> Define that ANSI Common Lisp uses the package name COMMON-LISP, not LISP.
> Define that the COMMON-LISP package has nickname CL.
> Since some symbols (e.g., T, NIL, and LAMBDA) might have to be shared
> between COMMON-LISP and LISP in implementations simultaneously supporting
> both, clarify that the initial symbols specified by ANSI Common Lisp as
> belonging in the COMMON-LISP package need not have a home package of
I like this. I wonder, though, if you might want to add that it would be
permissible for implementations to define "LISP" as a nickname for this
package, for the sake of backwards compatibility in new implementations
that wouldn't otherwise have a "LISP" package?
> Cost to Implementors:
> In some cases, this may even have `negative cost' because it will provide
> implementors a way of avoiding incompatible changes to released operators.
I agree; this approach will make it much easier for us to support the
standard with minimal incompatibility for existing programs. Trying to
support Zetalisp and Common Lisp sharing the same LISP package has been
enough of a headache without having to try to support two dialects of
Common Lisp that way.
Now we just need something in the *FEATURES* list to enable easy
distinction between standard-conforming and pre-standard implementations.