[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
>From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
>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):
(LET ((LOCAL (FIND-PACKAGE :LOCAL)))
(DO-EXTERNAL-SYMBOLS (SYM (FIND-PACKAGE :LISP))
(EXPORT SYM LOCAL)))