issue COMPILE-FILE-SYMBOL-HANDLING, version 3

[Patrick Dussud <dussud@lucid.com>]

   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
   Date: Thu, 20 Apr 89 10:46:06 MDT


   I don't think "load" is the right word here because it's an operation
   on files, not forms.  The forms in the file are executed as part of
   loading, of course.  Perhaps I can come up with some better wording on
   this, though.  I'll have to think about it.
I see your point. Maybe processed would convey what you want to say?


   I disagree -- this paragraph is the key to the whole proposal.  The
   previous items are requirements for a program to be valid.  This
   paragraph says how valid programs behave.  If we delete it, we will
   still have no statement of how symbols referenced in the source code
   for a file relate to the symbols in the compiled code for that file.

   I do not believe what this paragraph is trying to say is incompatible
   with the "current package" model because of item (2) -- if a symbol is
   accessible in *PACKAGE* (and hence has no home package information),
   the same symbol must also be accessible in the home package.  Now that
   I look over the exact wording here though, it does rather give the
   impression that implementations must remember the home package.
   Suppose I changed it to say:

      ...the interned symbols it references are found as if INTERN were
      called at load time with two arguments....
That's much better. 

Patrick.