Re: Issue: LISP-PACKAGE-NAME (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Thu, 22 Dec 88  15:35:09 CST
    From: David N Gray <Gray@DSG.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 
    >   Common-Lisp.

    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?

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.

For this reason, I think we should discourage or prohibit the placement
of a LISP nickname on the CL package.

Besides, ANSI CL supersedes CLtL, but ISO Lisp may not. Depending on how
it turns out, I could see people considering them siblings rather than
mother/daughter. I really believe the bit about not wanting to lock down
the name LISP for a dialect that may not be the unique favorite.

    > Cost to Implementors:
    > 
    >   Small.
    > 
    >   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.

In Cloe, we use a separate readtable for the different dialects, and each dialect
has its own *FEATURES* list. Although this seems like it would be confusing, it
works out pretty well in practice once you've made all the system tools understand
it. If we specified that CLtL and ANSI CL could have similar readtables but that
they must not be EQ (for the sake of #+ and #-), and if we defined that 
(NOT (EQ 'CL:*FEATURES* 'LISP:*FEATURES*)), then we could indeed have such a feature.

If I get a little time (worn out joke), I'll see about see about spinning off an
issue to deal with that and see if it flies. I know it's last minute, but I agree
with you that it would really grease the wheels of transition, so hopefully people
will find it palatable.