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

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

    Date: Fri, 27 Jan 89 20:01:47 CST
    From: alarson@src.honeywell.com (Aaron Larson)

    I have two comments with regard to this proposal;

    first, it should mention the user package (perhaps cl-user),

You're a little vague. I guess you mean it should say that the USER package
is called CL-USER and not USER.

I guess I think this is probably the right thing, since there is a contract
already in CLtL that USER should use LISP, and compatibility would be best
be maintained by making CL-USER, which must use CL, be different.

(None of this is compatible for Symbolics systems, of course, since CL is
 already a nickname for LISP, and CL-USER is already a nickname for USER.
 But personally think that's a problem we can ultimately dig our way out of.)

    secondly there is a much simpler way to get print/read inconsistency than
    that described in the proposal, just have *PACKAGE* bound to a package
    that does not use CL be current when printing.

I agree this is an issue, and should be documented, although in spite of its
simplicity, again I don't think it's a common event. The only time I've ever
done it has been in routines where I wanted to expose the home package. If
we document that the home package is not something you depend on, then portable
programs will not try to expose the home package, so I think the situation
will continue to be quite rare.

    I would feel better requiring CL:SYMBOL-PACKAGE returning the CL package
    for symbols defined in the spec.

The problem here is that CL:SYMBOL-PACKAGE may fail to be predictive of what
the printer will do. Supposing that you have a symbol SI:NIL which must be
the false value for Zetalisp, CLtL, and ANSI Common Lisp. If 

 (ZL:SYMBOL-PACKAGE   'SI:NIL) must return #<Package ZETALISP> 
 (LISP:SYMBOL-PACKAGE 'SI:NIL) must return #<Package LISP>
 (CL:SYMBOL-PACKAGE   'SI:NIL) must return #<Package COMMON-LISP>

then how will the symbol print? That is, what if I do (ZL:PRINT 'LISP:NIL)
or (LISP:PRINT 'CL:NIL)? It looks to me like the possibilities are:

 1. You must never share code between lisp dialects.
    This would be very sad. Important things can come from an ability to
    co-exist, and it's very easy to accidentally constrain things so that
    co-existing dialects only really work if you violate one or the other's
    spec.

 2. You should assume that ZL:PRINT will somehow pass information through
    to the symbol printer to say to print ZL:NIL and not CL:NIL or LISP:NIL.
    Analogously for CL:PRINT, etc.. Analogously for CL:SYMBOL-PACKAGE, etc.
    This would make CL:SYMBOL-PACKAGE and CL:PRINT internally consistent,
    at the cost of slowing down PRINT and SYMBOL-PACKAGE.

 3. You should assume that ZL:PRINT, CL:PRINT, and LISP:PRINT are really
    the same function, and that ZL:SYMBOL-PACKAGE, CL:SYMBOL-PACKAGE, and
    LISP:SYMBOL-PACKAGE are really the same function, and that some magic
    undocumented internal dynamic switch controls what `language' you are
    really in at any given time. This addresses the question of whether
     (CL:DEFUN LISP:IDENTITY (ZL:X) ZL:X)
    is a CLtL, Zetalisp, or Ansi Common Lisp program by defining that the
    answer is context-dependent. Also, this is less complicated than explicit
    data flow and still achieves internal consistency, but the dynamic 
    nature of the switch makes programs hard to prove correct. Binding the
    `current language' might affect things you didn't intend to affect, as
    is always the problem with dynamic switches.

 4. You should assume the home package for initial symbols in package 
    COMMON-LISP is not reliable, and assure that the binding of *PACKAGE* is
    appropriate if you plan to do code interchange between implementations.
    For example, (LET ((*PACKAGE* (FIND-PACKAGE "COMMON-LISP"))) (PRINT ...))
    will do exactly the right thing for code interchange.

I've oversimplified a bunch of things here, but I hope you can get the
basic idea from this presentation. As you can probably see, only option 4
seems suitably efficient to me, which is why I proposed it.

Keep in mind, too, that in these options we're really only free to
change what ANSI CL does. What Zetalisp and CLtL (and perhaps other
dialects to come, such as ISO) say really must be just taken as fixed.

I have to emphasize that I don't make this recommendation lightly. I
have worked for many years in the Symbolics environment, which must deal
usefully with Zetalisp and Common Lisp in the same environment. Also, my
Last two years I have been intensely involved in the design of Cloe, a
third implementation of Lisp which co-exists in the same environment under
a completely different set of restrictions than the other two.
In my work with Cloe, I initially tried to make SYMBOL-PACKAGE do as
you suggest and I found it leads to a house of cards which is doomed
to eventually topple. My suggestions about what to leave undefined are
motivated out of practical respect for the number of legitimate concerns
on all sides.

Moral: Better for programmers to understand that there are things on
which they cannot rely and against which they must program defensively
than for them to believe there are things upon which they can rely and
to have that belief turn out to have been a mirage.