Re: issue IN-PACKAGE-FUNCTIONALITY, version 5

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

Here is some wording that borrows from what you used, that says pretty
much what I intended to say in my original proposal. 

  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. 

As far as I can make out, there are two situations where the two
proposals specify different behavior:

(1) The situation where there is a symbol accessible in the
compile-time value of *PACKAGE*, but with another home package.  Your
proposal would have the loader INTERN the symbol in the load-time
value of *PACKAGE*, and mine would have it INTERN the symbol in its
compile-time home package.  Unless there is an existing symbol with
the appropriate name that is accessible in both packages, the
load-time home package of the resulting symbol would differ under the
two proposals.

(2) The situation where a symbol is external at compile time, but
where there is no such external symbol at load time.  Your proposal
would quietly INTERN it as internal symbol in *PACKAGE* if the symbol
were accessible in the compile-time *PACKAGE*, and otherwise signal an
error.  Mine would always just quietly INTERN the symbol as internal
in its home package. 

The more I think about this, the more I have come to believe that no
conforming program ought to cause either of these two situations to
arise, and that we could just leave the behavior unspecified in these
cases.  It's a user interface issue, much like what happens when you
incompatibly redefine a DEFSTRUCT.  Or, to give a stronger parallel,
it's like what happens when you load a file that was compiled with
some DEFSTRUCT definitions that are incompatible with the DEFSTRUCT
definitions that happen to be around at load time.  (Proposal
COMPILE-ENVIRONMENT-CONSISTENCY says that the behavior is unspecified
in that situation.)

As I understand it, one rationale for the proposal you suggest is that
it makes LOADing compiled files more like LOADing source files, in that
symbols that would be interned in *PACKAGE* when the source file is 
loaded ought to also be interned in *PACKAGE* when the compiled file
is loaded, regardless of what the compile-time value of *PACKAGE* was.

Here is an example to explain why I believe that the compile-time
value of *PACKAGE* -does- matter.  PCLS has two different packages,
the PSL package and the LISP package, which do not use each other.
Many functions, macros, and special forms with the same names exist in
both packages as distinct symbols with different definitions.  If I
have a file that really wants to use the Common Lisp definitions,
rather than the PSL definitions, the symbols from LISP package -must-
be accessible at compile time in order for the compiler to apply the
right set of macro expansions and use the right set of special form
compilers.  If the compile-time *PACKAGE* is such that the PSL package
macros get used instead, then the compiled file would end up
referencing functions that don't even exist in the LISP package, and
under your proposal you'd lose no matter what the load-time value of
*PACKAGE* is.  This is why PCLS ended up including an explicit package
prefix on all symbols in compiled files.  The same considerations
apply equally well when talking about user-defined macros and all the
other kinds of things that the compiler is allowed to "wire in" to the
code it compiles. 

Basically, what I would like to do is come up with a unified proposal
that is compatible with both of the existing ones where they agree,
and leave what happens in the situations where they disagree to be
explicitly vague.  In other words, it would place some additional
COMPILE-FILE/LOAD consistency requirements on conforming programs --
something along the lines of saying that the compile-time value of
*PACKAGE* must be the same as the load-time value, any symbols
referenced in the compiled file that are accessible in *PACKAGE* but
with another home package at compile-time must also be accessible in
both packages at load-time, etc.  (I'll obviously have to think about
this some more to get all the details right.)

Do you approve of this general direction?

-Sandra
-------