which package...

[Rob MacLachlan <RAM@C.CS.CMU.EDU>]

The Spice Lisp packaging rules are someething like this:
 LISP
    Anything which is:
      1] Defined in the manual.
      2] Needed to support something in the manual, e.g. debugger
	 commands.
      3] A potentially portable language extension, e.g. MULTIPLE-VALUE-SETF.
      4] User interface commands which should always be availble,
	 e.g. QUIT and SAVE-ALL-BUFFERS.
 SYSTEM
    Random implementation constants and system interface facilities.

The idea is that all symbols which are needed for writing portable
programs are available from the LISP package.  Packages only use type
SYSTEM package if they are doing system hacking.   The only
reservation I have about this scheme is with the "portable extensions"
being exported from the LISP package.  It would probably be a good
idea to put them somewhere else.

It seems that the big discrepancy between what we are doing and what
other people advocate has to do with the SYSTEM package.  There seem
to be two interpretations of what the SYSTEM package is for:
  1] The system package provides facilities needed for systems
     programming. (Spice Lisp)
  2] The system package provides system dependent user interface
     facilities. (Greek, KMP)
In the first case, random users clearly don't want to use the SYSTEM
package.  In the second case, they definitely do.  I would argue that
if the system package has facilities which you always want to be
there, then it should be in the default use list.


    From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
    Subject: What's in the standard packages?

    1.  The LISP package should have external symbols which exactly are the
	Common LISP standard.
Symbols not mentioned in the manual may need to be exported from LISP
in order for things to work.  This is because environment interface
functions are incompletely defined in the manual.  It would be silly
to export a function from LISP and not be able to use it beacuse some
magic frob it needs isn't available. 

    2.  Either the SYSTEM package or some implementation-specific package
	should contain any implementation extensions to Common LISP.  Might
	as well make this the SYSTEM package.
I don't think extensions should come from the SYSTEM package.  It
seems to me that there is a difference between a language extension
and a system dependent feature.

    3.  The USER package should use both the LISP and SYSTEM packages.

    4.  What should MAKE-PACKAGE use by default?  Clearly the LISP package.
	Probably not the SYSTEM package, although this would result in an
	incompatible change for any implementation that currently puts all
	public symbols in the LISP package.  Such is life.
It is pretty wierd to say that USER should use the SYSTEM package yet
the default shouldn't include SYSTEM.  USER is nothing if not the
default environment.


    Date: Sunday, 9 March 1986  18:48-EST
    From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
    Re:   Can, could, may, might, must, ...

    The manual seems to take no stand on what should -not- be in the
    LISP package.  It says that the things in the book should be, but
    it does not say, for example, whether it's appropriate to have the
    LISP package use the SYSTEM package. ...

    The main reason is that this makes porting between dialects a
    pain. Suppose that some implementation has a symbol SYSTEM:FOO
    which is a system constant.  CLtL does not prohibit that symbol
    being placed on the LISP package. But if I build and application
    which builds a package on LISP, I have no assurance that doing
    (DEFVAR FOO 3) will not be trying to redefine a system constant.
    ...
This seems confused.  The packages which LISP uses has no effect on
packages which use LISP, since inherited symbols become internal
symbols.

  Rob