Re: issue IN-PACKAGE-FUNCTIONALITY, version 5

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

A few comments on your amendment:

I am not sure why you think NIL must be treated specially, any more
than any other external symbol in the Lisp package.

I think the idea of trying to confine WITHIN-PACKAGE to being the
first form in the file is bogus, and the difficulty you have in
defining "first" is one reason why.  Another thing is that the obvious
replacement for the "Put In Seven Extremely Randoms" convention is to
put a DEFPACKAGE at the top of the file, followed by a WITHIN-PACKAGE.
(I know that this convention is generally regarded as broken at least
in the case of multiple files in the same package, but many users have
tried to follow the recommendation given in CLtL, and this is a
reasonable thing to do if you've got a short module all in one file.)
The compile-time effects of WITHIN-PACKAGE can be well-defined
regardless of whether or not it appears first in the file, anyway.
Perhaps if I think about this a while longer I can come up with an
alternate specification that will still let you include the special case
for symbols accessible in *PACKAGE* and avoid the kind of problems I
mentioned in my previous message.

As to splitting this up as a separate issue, that might be a good idea
since it appears there will be at least two alternatives.  I think
IN-PACKAGE-FUNCTIONALITY:NEW-MACRO ought to include the parts about
adding WITHIN-PACKAGE, removing IN-PACKAGE, and deleting the
troublesome paragraph in CLtL that implies COMPILE-FILE has to treat
the package functions specially (since the whole motivation for making
WITHIN-PACKAGE a macro is to avoid this requirement).  I will start a
new compiler issue (called COMPILE-FILE-SYMBOL-HANDLING, unless I get
a better suggestion), that combines the parts from this issue and
issue CONSTANT-COMPILABLE-TYPES that deal with what package symbols end
up in.  Sound OK?

-Sandra
-------