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

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

> Date: Thu, 20 Apr 89 09:25:06 PDT
> From: Patrick Dussud <dussud@lucid.com>
> 
>      (1) The value of *PACKAGE* when a top-level form in the file is processed
> 	 by COMPILE-FILE must be the same as the value of *PACKAGE* when the
> 	 code corresponding to that top-level form in the compiled file is
> 	 executed.  In particular:
> 
> You mean loaded instead of executed right?

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.

>      If all of these conditions hold, then when a compiled file is
>      loaded, the interned symbols it references are found by calling
>      INTERN at load time with two arguments, the name of the symbol and
>      the package with the same name as the compile-time symbol's home
>      package.  If no such package exists, an error is signalled.
> 
> I think this should be removed. It clearly is overspecification. We should
> specify behaviour of conforming programs. You are trying to describe the
> behavior of an implementation. Besides, this is incompatible with the current
> package practice, because they lose the home package when they dump. 
> I will be perfectly happy with just the requirement 1 and 2.

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....

-Sandra
-------