Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 1

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

> Date: Wed, 8 Feb 89  10:35:45 CST
> From: David N Gray <Gray@DSG.csc.ti.com>
> 
> There really shouldn't be anything wrong about using SELECT-PACKAGE
> multiple times within a file as long as it is used at top level so that
> the compiler knows that the current package is being changed.

Actually, I agree with you.  The problem has to do with the notion of
the "current package" that proposals CURRENT-PACKAGE and
REQUIRE-CONSISTENCY depend on.  If the value of *PACKAGE* is allowed
to change throughout the file, which one is the "current package" that
is used to decide how to dump the symbols?  Many compilers save up all
the symbols and dump them after the entire file has been processed.
Alternatively you could say that the "current package" is the value of
*PACKAGE* when the top-level form containing a reference to a
particular symbol was read in, or when the top-level form was actually
"processed" by the compiler (note that these are not the same).  Plus,
you might end up having the same symbol referenced in several places,
with different values of *PACKAGE* in each place. 

In my view, this confusion is a good reason for supporting proposal
HOME-PACKAGE.

> A more troublesome situation which might be worth a warning is the use
> of the "dangerous" package functions [CLtL p. 173]; if our compiler sees
> a top-level call to SHADOW, SHADOWING-IMPORT, UNINTERN, or UNEXPORT, it
> purges the affected symbols from the table of objects already dumped, so
> that any subsequent references will be interned with the modified
> package.  We found this necessary to avoid some strange and unexpected
> behavior.

CLtL already warns about these functions being "dangerous" in several 
places.  I don't really think we need to reiterate that in this proposal.

-Sandra
-------