[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A-Packaging we will go...
Date: Fri, 12 Apr 85 10:00:19 EST
[My new comments are in square brackets -- Paul.]
Well, Mr. Moon, I gave your comment some thought. It was a bit terse,
but perhaps this is what you meant:
What happens if a macro calls a function during the expansion of a
macro call? If that function is in, say, the "USER" package, and the
compiler were to make the current package "SPECIAL-COMPILER-PACKAGE-
THAT-NO-ONE-ELSE-USES", then indeed the function wouldn't be found
at compile time.
What if the function was in the LISP package? Does your special compiler
package inherit from there or doesn't it? If it doesn't, macros can't
run. If it does, you can't tell whether a symbol came from there via
package prefix or via inheritance.
[Well, as you say, it must inherit from the LISP package.
But why do I care whether the compiler can tell that the symbol had
a package prefix or inherited the symbol? The fact is that the symbol
is in the LISP package, so the fast loader better find it there.]
I thought the whole point of your suggestion for a special compiler package
was that you cared.
But then again, it wouldn't be found if the user didn't happen to be
in the "USER" package when compiling the program. If the program
must be compiled in the "USER" package, it ought to do an IN-PACKAGE
at the top.
If I read you wrong, please let me know.
By the way, here's what VAX LISP currently does: If the compiler goes
to dump a symbol which is in the current package (not any special
compiler package), then it dumps it without a package. This means
it will be loaded into the current package at the time of loading.
In other words, it does the same thing as PRINT. This is what our compiler
[But do we agree that's correct?]
I believe that it is inherently the best thing that can be done, if you grant
the compiler uses the Lisp READ function as its lexical analyzer.
I don't think this is quite right, since it means that if I'm in
the "FOO" package when I compile, and I say FOO::SYM, and then I'm
in "BAR" when I load it, SYM will end up in "BAR" rather than "FOO".
To avoid this problem, I think you need the special compiler package.
A better approach is for the compiler to tell the loader what the value
of *PACKAGE* was when the file was compiled. If the loader binds
*PACKAGE* to the same value (that is, to a package with the same name)
when the file is loaded, symbol names in the compiled file will be
interpreted as the compiler intended when it dumped them. This approach
works well for us. Of course the user can get into arbitrary amounts of
trouble by changing package definitions between the time a file is compiled
and the time it is loaded, but that is inherently unavoidable. For instance,
if the source file referenced FOO::SYM, and SYM was imported or inherited
by the source file's package at compile time, but not at load time, then
the wrong SYM will be referenced.
[I don't see how this solves the problem I described above with the FOO
and BAR packages. Seems to me that SYM would end up in the FOO package
alright, but so would an unqualified symbol, say SYM2. But SYM2 ought
to end up in BAR, the current package at load time. To summarize:
source file, compiled when FOO is current package:
fastload file, loaded when BAR is current package:
FOO::SYM1 ; Better end up in FOO.
SYM2 ; Better end up in BAR.
This problem derives entirely from the (doomed) attempt to compile a file
in one package and load it into another. You cannot expect reasonable
results from this. Hence my suggestion for the loader to ensure that the
file is loaded into the correct package. If FOO was not the correct
package, why did you compile it in that package? Or, to ask the question
another way, why did your compiler compile it in the wrong package? This
relates to the other discussion about the file attribute convention (-*-).
This piece of mail is getting rather long. I suggest that if we need to
discuss this further, we should prune it. I myself don't have anything
further to say.