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

[no subject]



Please, don't think that I made a suggestion that the keyword
package be the superior of the user package.

I mentioned it only because I was explaining that it doesn't work.
Unfortunately, nobody seems to have noticed the explanation of
why it doesn't work, and everyone is now going off gung ho to
implement it, not realizing that it is a screw.

I think that we want these three goals:
Naive users should be able to write code without realizing that
packages exist;
Such code should be compatible with Maclisp when it uses functions
which exist in Maclisp;
The cold boot should not have to contain a list of all the keywords
that can EVER exist.

The only way to satisfy all these goals is to make the user package
be the same as the keyword package.  I don't want to try to defend
this statement here because defending it involves dealing with each
possible alternative individually, but the reason why it does not
work to make the keyword package the superior of the user package
is that this sequence of events is possible:

FOO is a keyword used by a function which isn't loaded.
The system as booted contains no calls to that function, and there is
no FOO in KEYWORDS yet.
1) the user happens to type FOO for some other reason.
FOO now exists in USER.
2) the user loads the file which defines that function.
FOO now exists in KEYWORDS.
3) the user tries to call the function using the keyword FOO.
However, he gets the FOO in USER rather than the one in KEYWORDS.

This can only be prevented if KEYWORDS starts out containing all the
symbols it is ever going to contain, just like GLOBAL and SYSTEM.
It's true we have GLOBALIZE for GLOBAL, but that uses forwarding.  It
will work for function symbols but it won't work with keywords, which
need to be EQ.

All this was thought about in great detail before the package system
was designed, and if you have any plans to change it you should manage
somehow to retrieve that file and see why the other alternatives were
discarded.  Unfortunately, I can't remember the name of the file, but
it probably started with PACK.  It was on LMDOC.