[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


>LISP - a pure CL package to make the hard-core portability folks happy.
>LISP:*LOCAL-PACKAGE* - a variable holding the a package which is named 
>   (hopefully uniquely) in a system-dependent way by each implementation.
>   This should use LISP. There's a minor issue about whether this should
>   be a system constant (no stars) or a settable variable. I'm not fussy.
>USER - a package which uses LISP and which uses the package which is the 
>   value of LISP:*LOCAL-PACKAGE* .
>MAKE-PACKAGE,etc - as before, but if no package is explicitly given to 
>   use, the default would be LISP:*LOCAL-PACKAGE* . Writers of most portable
>   code would use LISP explicitly.

I agree with the intention, but some of the details are unclear.  There
are two ways the local-extension package could work:

 (1) LISP:*LOCAL-PACKAGE* exports only the extension symbols.  USER and
other user-created packages must use both it and LISP.
 (2) LISP:*LOCAL-PACKAGE* also exports all the normal external symbols
in the portable LISP package, except those that it might want to shadow
with distinct versions.

Your descriptions of USER and MAKE-PACKAGE above seem to imply
different choices.  Anyway, for several reasons (2) seems cleaner:
 It is less of a change from the current spec since packages created
with the `default' still will only use a single package (even though
it's name might not be LISP) rather than two packages.
 If an implementation for some reason shadows a standard function
symbol under (1), the user cannot naively create a new package which
uses both LISP:*LOCAL-PACKAGE* and LISP without also doing explicit

If we choose (2) it is insufficient (or irrelevant?) for
LISP:*LOCAL-PACKAGE* to use LISP.  Inherited symbols are not
automatically exported.  The following has to happen (for simplicity,
assuming no shadowing is necessary):