The compiler and packages.

[David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>]

    Date: Thu, 11 Apr 85 15:35:16 EST
    From: greek@DEC-HUDSON

    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.

    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.

    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.