Packages & Compiling

[Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>]

    Date: Mon, 12 Jan 1987  20:08 EST
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>

	Date: Monday, 12 January 1987  19:15-EST
	From: Timothy.Freeman at theory.cs.cmu.edu
	Re:   Packages & Compiling

	... Allowing the compiler
	to depend upon the package environment when it is compiling a
	not-in-line function call doesn't allow it to produce better code.

    True; it simply allows the compiler to function.  The basic problem is
    that if you use READ to read, there is no way to intern the symbol the
    same way at load time, since the reader threw away the information
    about how the symbol was read.

    For example, if the source file contains the symbol reference FOO::X,
    but X's home package is actually BAR, then the compiler will dump code
    which does the equivalent of reading BAR::X at load time.  The result
    will be the X currently accessible in the BAR package, regardless
    of what symbol is currently accessible in the FOO package.

    In contrast, if FOO::X was read again by loading the source, then the
    symbol would be read as whatever X is accessible in the FOO package.

      Rob

This has been discussed in the past.  If the compiler doesn't
dump BAR::X, but rather just "X" (just like the printer would),
then the loader will make the same decisions the compiler
did.  Dumping should be kept strictly analogous to printing,
and loading to reading, so far as package-prefix hacking is
concerned.

This certainly needs to be made a part of the standard, or
implementors aren't going to realize this and their users
are going to have the problems you refer to.  We didn't
get it right our first time around, either.

This doesn't confer immunity to package-heirarchy changes,
of course.  Among the ways you can lose at load time
include:

1)  Refering to a package that is no longer there.  Obviously,
    a source change would have been necessary.
2)  Making an exported symbol be unexported.  (Although
    a source change might have been necessary in this case,
    too).
3)  Moving a symbol from one package to another, when
    you want to continue refering to the same symbol.  Of
    course, you have to change the source anyway, so it's
    not suprising you have to recompile.
4)  You said BAR::X, at compile time X was accessible in
    FOO, but at run time, it was not.  No source change is
    necessary, because you already had it right.

But in practice, these aren't very serious, while it
is much more serious if you can't change which X
you import into your package.  In fact, I think #2
and #4 are the only cases where you really do suffer
from READ not preserving information.