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

[David N Gray <Gray@DSG.csc.ti.com>]

For the "current practice" section, the Explorer currently implements
proposal COMPILE-FILE-SYMBOL-HANDLING:HOME-PACKAGE; that's what we
settled on several years ago after trying it both ways.  For your
information, following is the recollections of the person who was
working on that at the time.



------- Forwarded Message

Date: Tue, 7 Feb 89  18:00:49 CST
 From: John Kolts <kolts@dsg.csc.ti.com>
Subject: Re: fasdumping symbols
To:   David N Gray <Gray@DSG>
Cc:   Kolts@DSG
In-Reply-To: Msg of Fri, 3 Feb 89  11:00:43 CST from David N Gray <Gray@DSG>

David,

   My primary motivation was compile/load consistency.  I thought it
was important that during loading all symbol references should resolve
to the same symbol as they would have during the compilation.  If, for
instance, the packages used by *package* were different at compile time
than at load time, my approach would still intern the accessible symbols
in the "right" package during loading.  Thus loading an XLD should
result in identical behavior regardless of changes to the package
structure in the load environment.  Of course, such an approach means
that loading the XLD could give results incompatible with loading the
LISP file directly, but I felt that if behavior consistent with some
altered package structure was desired, the file should be recompiled, a
relatively small price to pay for the benefit of this consistency.

A related consideration was that remembering the home package seemed to
be important for proper macro expansion in certain cases.

What was apparent was that there were several defensible approaches,
none of which was obviously the absolutely right way to handle certain
pathological situations.  Making the expected behavior explicit in a
standard is a good idea.

					-John-

------- End of Forwarded Message