LISP:*LOCAL-PACKAGE*

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

    Date: Thu, 22 May 1986  22:24 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    ... I'm ready to agree that the path of maximum sanity is to require
    that the LISP package contain only the symbols of pure Common Lisp, 
    and that we create a new standard package (I like the name "LOCAL") 
    for containing the local lisp environment, with possible extensions.

I think we should agree to disagree on naming anything that is implementation
specific. If two implementations have a LOCAL:FOO function and they don't do
the same thing, it will be hard to detect the problem until runtime. Again,
the absence of VAXLISP:FOO in the Symbolics environment or the absence of
SYMBOLICS:FOO in VAXLISP will be easy to detect. After all, to use the 
implementation stuff, people will have to have read the implementation-specific
manual, which will tell them the package name. 

Also, and importantly, I can create a VAXLISP:FOO if I need it on a 3600 in 
order to not have to edit the source file containing the reference. If both
implementations call their extension LOCAL:FOO, the fix is not so easy to make
because some other code I'm using may already reference Symbolics' LOCAL:FOO
and may not be happy if I bash that definition with something to make some ported
VAXLISP code happy.

    I'd like to see some variable that holds the current default package for
    MAKE-PACKAGE, with the default default being LISP.

As long as a portable program can specify LISP explicitly and not have to worry
that this variable will override that, I'm agreeable to that. In fact, I don't 
see the use of it, though, unless you allow the default default to vary from
implementation to implementation. In other words, I think it's fine for programs
that don't say they want LISP to get whatever they get -- all my programs will
say LISP so they'll not be bothered by this feature. You might as well let VAXLISP
make this variable be #<Package "VAXLISP"> and Symbolics let this package be
#<Package "SCL">, etc. I'll call this variable *LOCAL-PACKAGE* for purposes of
discussion here; I'm not wedded to the name -- another possibility might be
*NATIVE-PACKAGE*.

    We should encourage implementations (maybe require, but I'm not sure
    about this) not to extend the language by adding keywords and other
    non-standard options to the functions in LISP, but to put such
    extensions in LOCAL instead.

I agree, but rather than "LOCAL" the value of *LOCAL-PACKAGE*.

    Once we start considering exactly what goes into the ANSI/ISO spec (I'll
    be sending a message about this soon, probably over the weekend), I'll
    propose this for formal consideration.

OK. This is starting to sound pretty good. Based on your message and the 
others that have gone by, what would make me happy would be...

 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.

At this point, I'll back off a little and admit that some classes of portable 
code will usefully be able to take advantage of LISP:*LOCAL-PACKAGE* . Portable
programs can't be coded in an environment where the local package is active
because the author won't know what the program will mean in an arbitrarily
mucked up environment. Macsyma is a good example of this kind of program.

But some portable programs, though written in a portable subset, might want to
be able to portably extend whatever environment was available on the local
machine. An example of this might be GLISP. I would expect such a program to
be written in some package (GLISP-INTERNALS, I guess) which used only LISP, 
but which sometimes manipulated LISP:*LOCAL-PACKAGE* -- particularly for the 
purpose of creating a GLISP package based on LISP:*LOCAL-PACKAGE*. Code written
in such a GLISP package might not be portable even though it could built by
a portable program. (I'm kinda handwaving the GLISP example here because I'm
not familiar with its details; if my example doesn't hold up, perhaps you can
go back and re-cast this paragraph using AMORD or FRL or some other layered
language as an example with better results).

Thoughts, anyone?