Re: LISP:*LOCAL-PACKAGE*

[hpfclp!diamant@hplabs.ARPA]

> From: Kent M Pitman <hplabs!KMP@SCRC-STONY-BROOK.ARPA>
> 
> 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.

Great.

> 
>  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.

It should also export all of LISPs exported symbols, and all of the symbols
exported from LISP should be homed in LISP.

You have convinced me that the name of the local package should not be
standard, but instead to use a standard mechanism to access it.

If you allow *LOCAL-PACKAGE* to be a variable, you will shoot yourself in the
foot.  What happens if you change the value?  Will all subsequent MAKE-PACKAGEs
reflect the new value (good idea)?  So far this is no problem, but if you
want to really make it control the default environment (otherwise why not
use a constant), it should also change the use list of the USER package.
There is currently no mechanism for packages on the use list to be tied to
the value of a variable (nor should there as it would make manipulating the
use list more complicated).  You would require a function as I had suggested
in a previous message or an object with a setf method in order to be able to
change the use list of the USER package.  It is conceivable that the USER
package would use the original value, and subsequent MAKE-PACKAGEs would use
the current package, but it seems conceptually unclean.  My attitude
about this is due to my view of the USER package as a reasonable place
for portable programs to live (which differs from Alan Snyder's view).
Given that view, I would like the USER package to have the same
characteristics as ones I make with subsequent calls to MAKE-PACKAGE.

I had always assumed that the USER package should use LISP (as it says in
CLtL) and nothing else.  I don't mind having it use the default environment
for convenience, but realize that this makes programs which are now portable
(in that they assume that no less and no more than what is defined in CLtL
is in the implementation on which they run), no longer portable until they
change all their MAKE-PACKAGEs to explicitly use LISP, so that they don't
get the default environment and/or change the value of *LOCAL-PACKAGE* to
be LISP.  I would be happier if a mechanism were set up where the default was
the current status quo (i.e. the bare environment), but the variable (or
whatever mechanism used) could be set to the implementation dependent package.

>  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.
> 
> 
> Thoughts, anyone?

I think it is time we start thinking about writing a guide for writing
portable programs in Common Lisp.  It is clear that this is not as simple
a matter as had originally been suspected, and at present neither implementors
nor users have such a guide.  It should be part of the ANSI standard
document.

	John Diamant