Re: Issue: PACKAGE-CLUTTER

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

We had extensive discussions of what should go in the USER package a
while back on Common-Lisp. I was an advocate of a pure USER package,
but I eventually decided it was not a battle to be won and have since
come to believe that it is even the right thing for the USER package
to contain implementation-dependent junk.

This time around, I deliberately avoided the issue of the USER package
in this proposal because I think it's a lost cause. If we just tell
people that the USER package's sole purpose in life is for you to have a
package to stand in initially while you type (IN-PACKAGE
'something-else), and if we tell people straight out that no portable
programs should ever expect to run in USER, I think we will be in fine
shape.

I am susceptible to the idea of LISP containing internal symbols, but
I don't want to say that if we don't have to. The reason is that it
does affect what DO-SYMBOLS will do, and so it will be a place where
portable programs will behave differently on a documented package.
It also means that we may get opposition to later extensions because
someone has a LISP::something which collides unfavorably with a 
LISP:something that is proposed. All in all, I see no reason for system
programming not to be done in SYSTEM or some such and (DEFUN LISP:xxx ...)
done where appropriate.

Another problem this will avoid is the Zetalisp problem where they have
a few things like EVALHOOK which are both exported functions and internal
(special) variables. The internal variable accidentally shows through
because of an unintended name collision. This sort of thing is easily
fixed once noticed, but is just another error waiting to happen which
could be avoided by programming in another package and accessing LISP
only when you mean to. [Arguably this is yet another indictment of the
package system as a whole. Oh well.]

I hope this doesn't launch into an interminable discussion on this
issue. The bottom line is that I want to keep hands off of USER and I
am prepared to immediately give in on allowing LISP internal symbols if
it looks like a fight will ensue. [Whatever we decide about the 
internal/external issue should be explicitly stated to avoid confusion.]