A package to contain Common LISP extensions.

[Jonathan A Rees <JAR@MC.LCS.MIT.EDU>]

    Date: 0  0 00:00:00 EST
    From: BACH::GREEK <greek%bach.decnet at hudson.dec.com>

    Of course DEC's EXTENDED-LISP package would contain different things
    than Symbolic's.  That's the purpose of the EXTENDED-LISP package.
    Perhaps LISP-EXTENSIONS would be a better name.  I just think that
    everyone should agree on the name of the package to contain their
    extensions.  Then a user would at least have a place to start.

I don't see why there should be agreement, as each implementation's
extensions will be different.  In fact, I would think each
implementation would want its own package name for its extensions, in
order to improve readability and reduce the potential for accidental
name conflicts (which could otherwise be painful to track down).  Also,
one could imagine creating compatibility-mode implementations of one set
of extensions to co-reside with another set, making it even more
desirable to have disjoint packages.

The only reason I can think of for having a standard name for a package
of extensions is to give users a way to create "things like the USER
package" which have local extensions.  This seems of marginal utility in
portable code, but perhaps a standard nickname would be in order if
people think it's important.

Of course all this begs the question of how to avoid package name
conflicts, but that's not a new problem created by this situation.  I
think a package name registry would be a good idea, although not a
complete solution; the only problem with it would be getting people to
make use of it.

---

Having attempted to write portable CL code, and having repeatedly
tromped on implementation-dependent things in the LISP package which I
would have preferred to not be there (not just symbols like QUIT and
HELP, but definitions as well - e.g. Symbolics Common Lisp defines an
IGNORE function), I want to put myself on record as opposed to putting
non-CL things in the LISP package or in value (function, etc.) cells of
symbols in the LISP package.

As long as I'm flaming on this subject, I'll mention my idle desire that
the HOME package of symbols in the LISP package be defined to be the
LISP package.  This would permit true read/print symmetry (e.g.  across
implementations or different versions of the same implementation) for
shadowed LISP package symbols.

Jonathan