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

LISP package

    Date: Mon, 10 Mar 1986  09:16 EST
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    I disagree rather strongly with the view that the Lisp package should be
    exactly those symbols defined in the Common Lisp manual and no others.
    My understanding of what these packages are for is based in part on the
    Zetalisp package system, which was the starting point for the one in
    Common Lisp.

Please don't confuse the Zetalisp package system with the Zetalisp
GLOBAL package.  The GLOBAL package is a crock of which at least half
is garbage and shouldn't be there.  I'll let KMP tell you how it is hard
enough to write portable programs with extensions to functions in the CL
package, which will be after he tells you how to get screwed by having
non-CLtL symbols in the LISP package, which I thought he did in his
original message.

    The Lisp package has special status, in that it is the package that is
    included by default in all others.  It wants to contain those symbols
    that should be accessible to typical applications in a given system --
    the default set of accessible names.

Wrong.  The LISP package contains the Common Lisp language.  Anything
else, ANYTHING, is not Common Lisp, but rather an extension.  Extensions
belong in some other package or packages.  Applications can use those
other packages in addition to LISP.  This is a matter of documentation
by vendors for people writing such applications.

    The System package is for system-interface stuff and dangerous
    implementation-dependent operations that do not want to be trivially
    accessible to the average application.

    I agree that it would occasionally be useful to have a package that is
    guaranteed not to have anything in it that is not part of the Common
    Lisp standard.  We could create a new package, named "standard" or
    something like that, to do this job.  Or, I suppose, we could say that
    the Lisp package does this job, and create a new package named "default"
    or something that contains Common Lisp plus the local extensions.  In
    that case, "default" would replace "lisp" as the package used by default
    when a new package is created.  That's a more incompatible change for
    most implementaitons.

    I certainly do not like the idea of "system" being used to hold the
    local stuff, and of folding it into the default.  Then we would just
    have to create another package to hold the dangerous "system" stuff like

    -- Scott