[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Problems with packages
Date: Thursday, 1 May 1986 22:53-EDT
From: Kent M Pitman <KMP at SCRC-STONY-BROOK.ARPA>
To: Common-Lisp at SU-AI.ARPA
Re: Problems with packages
...
What happened was that I hit a bad timing window and it tried to resolve
the `FOO' package at the instant the package was created but before the
special stuff (like shadowing, importing, etc.) had been done. ...
Sounds like an environment issue to me :-)
While I'm on the subject of packages, I have a few other gripes to
air...
I'm really bothered that I have to say symbols as arguments to
shadow. The 3600 implementation allows me to use strings, which CL
doesn't define. CL should -require- strings as arguments to this
function and should not allow symbols. Giving symbols as
arguments to this function forces things to get created wrong and
then hopes that things will get cleaned up correctly afterward.
This reduces the ability to error-check if the symbol to be
shadowed had already been interned for some reason other than the
call to shadow.
I don't quite follow what you are saying about "things getting created
wrong." If the call to shadow is read in the package which them
symbols are to be shadowed in, then:
1] The symbols get created as internal symbols in the package, in
which case shadow does nothing but update the shadowing symbols
list.
2] The symbols were already directly present in the package, in which
case both reading and shadowing do nothing but update the
shadowing symbols list.
3] The symbols are inherited from somewhere, in which case the
"wrong" symbol is read, but nothing is "created wrong", since the
symbol already existed.
It is a bit odd that SHADOW takes a list of symbols and then just uses
the names, but it doesn't have any bad side-effects that I can see. I
would guess that consistency was the motivation for using symbols
everywhere. Using symbols also lets those of us who dislike uppercase
type the names of the arguments in lowercase.
Rob