A-Packaging we will go...

[greek@DEC-HUDSON]

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

    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
does, too.

[But do we agree that's correct?]

    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:

	FOO::SYM1
	SYM2

fastload file, loaded when BAR is current package:

	FOO::SYM1	; Better end up in FOO.
	SYM2		; Better end up in BAR.
]