LISP-PACKAGE-NAMELISP.
Further, use of the name unqualified name LISP by the ANSI Common Lisp community is inconsistent with ANSI's expressed position to ISO that the term "LISP" names a language family rather than a specific dialect within that family.
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 Common-Lisp.
Similarly, rename the package USER to be COMMON-LISP-USER with nickname CL-USER.
LISP package and the ANSI Common Lisp CL package proposed here:
(EQ 'LISP:T 'CL:T) => not specified, due to this proposal, but probably T
(EQ 'LISP:CAR 'CL:CAR) => not specified, due to this proposal, but probably T
(EQ 'LISP:FUNCTIONP 'CL:FUNCTIONP)
=> not specified, due to this proposal, but since FUNCTIONP is
changed incompatibly between CLtL (LISP) and CL (ANSI), there
are good reasons why this might return NIL.
(SYMBOL-PACKAGE 'CL:T)
=> not specified, due to this proposal. Perhaps #<Package CL>,
perhaps #<Package LISP>, or perhaps something implementation-specific.
(SYMBOL-PACKAGE 'LISP:T)
=> not specified, not due to this proposal, but because CLtL didn't
specify this explicitly.
Not only is this important the CLtL and ANSI Common Lisp communities, but also, if we continue to use the name LISP, it sends a signal to the ISO Lisp community that the "latest and greatest" Lisp should use the generic name LISP, and they may try to use it as well. If ISO Lisp turns out to be very different than ANSI Common Lisp, there may be motivation down the line for having ISO Lisp and ANSI Common Lisp co-resident, and conflicts will inevitably arise if both want to use the name LISP. This will almost certainly lead to a confrontation where one Lisp dialect tries to force the other out by the artificial means of asserting its right to this generic name. Choosing a name which compatibly admits the option of introducing other dialects into the environment at a later date without conflict is a good way to avoid a class of potential problems.
Although there are a few problems which could come up due to the symbol package of initial symbols being unspecified, experience with implementations that do this suggests that they are very few. Problems occur only in the rare circumstance that all of the following conditions are met:
- A symbol S on the LISP package but with home package H (that is not "LISP") is shadowed in some package P of implementation A.
- A program F in package P uses the shadowed symbol H:S by an explicit LISP: or H: package qualification. (Only the case of using "LISP:" is interesting, of course, since if H were named explicitly, we would be outside the bounds of portable code).
- The program F, referring to H:S, is printed out in implementation A while using package P (or some other package that shadows S, so that the H package qualifier appears explicitly) and an attempt is made to re-read it in implementation B.
- Implementation B has no package named H, has a package named H but no external symbol named S, or has a package named H with external symbol S but the symbol H:S has different semantics in implementation B than it did in implementation A.
In practice, this hardly ever happens. It would happen even less if programmers were explicitly alerted that it was a potential problem they needed to guard against.
COMMON-LISP with nicknames CL and LISP. As such, this would be an incompatible change for Genera.In some cases, this may even have `negative cost' because it will provide implementors a way of avoiding incompatible changes to released operators.
In some cases, this may even have `negative cost' because existing code would be able to continue to run in implementations which chose to support both CLtL's LISP and ANSI Common Lisp's CL packages, thereby allowing developers to put off a massover changeover, perhaps doing the transition more incrementally.
Worse, different implementations faced with the same set of hard choices about which spec to violate in order to concurrently support two dialects might not make the same choices, leading to even more gratuitous incompatibility.
ANSI's position in ISO that we are not trying to legislate the meaning of -the- LISP dialect would be weakened.
LISP and CL packages seems unaesthetic because it appears to diminish print/read invertability, but as observed above, that case is rare.
Failiing to specify a way in which lisp dialects can be co-resident is also unaesthetic because in practice implementors with a need to do this will do so whether the standard allows them or not, and it will be a source of severe divergence among implementations.
LISP" since Cloe's concept of what the "LISP" package is differs from Genera's concept of what the "LISP" package is, yet they are forced by efficiency constraints to share the same symbol. It is Pitman's belief, based on extensive experience with Cloe, that failure to pass this proposal (or something very like it) will lead to all sorts of trouble for Common Lisp users and implementors down the road.
Pitman strongly supports this proposal.
Additional comments:
Is it permissible for implementations to define "LISP" as a nickname for this package, for the sake of backward compatibility?
Anyone wanting to make LISP a nickname could just as well create a LISP package which simply imported the appropriate symbols from the CL package.
With only modest additional effort, they could try to make new symbols where feasable (especially for most functions) and put borrowed functions plopped in their function cells. The amount of additional storage is small (compared to implementing a whole new lisp), but it would leave open the possibility for users upgrading the level of compatibility without hurting the core system. eg, if I wanted APPEND to signal an error on dotted lists, I would not consider redefining the system's APPEND for fear of breaking the world, but if they told me that nothing depended on LISP other than compatibility code, I might feel ok about redefining (or doing SHADOWING-IMPORT of LISP:APPEND on a per-implementation basis (with appropriate sharp conditionals)) in order to up the level of compatibility.
In fact, though, my guess is that implementations which are not going to do a serious compatibility effort are better off leaving the package missing. My experience has been that customers are often happier growing their own compatibility [or getting it from a public library] than being stuck with something which really doesn't do what they want but which seals off the place in the namespace which they needed in order to do their own thing.