[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Packages & Compiling
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.
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
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
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,
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.