[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 1
- To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Subject: Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 1
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Wed, 8 Feb 89 10:35:45 CST
- Cc: cl-compiler@sail.stanford.edu, moon@stony-brook.scrc.symbolics.com
- In-reply-to: Msg of Wed, 1 Feb 89 16:07:34 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Sender: GRAY@Kelvin.csc.ti.com
> (a) If any top level form in a compiled file changes the value
> of *PACKAGE*, other than a SELECT-PACKAGE appearing as the first
> top-level form in the file, the results are unspecified.
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.
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.