Re: Packages & Compiling

[Timothy.Freeman@theory.cs.cmu.edu]

We could make it possible for the compiler to maintain the interpreted
semantics in this case by making the read function take an optional
parameter, which would be function to use to intern the symbols
encountered.  The default value of this parameter would be #'intern.
When the compiler is running, the value of this parameter would be a
function that looks at compiler data structures instead of the package
world.  This would have several advantages:

  It would allow the compiler to be reentrant.
  It would make it possible for the compiler to understand
     a "(use-package :foo)" (or any other package manipulating form)
     without having to modify the package world.

Actually, the compiler is not required to call read, so this could
have been done on the initiative of the language implementor without
any change in the standard.  I think that the following specification
of the compiler is implementable (argue with me if you disagree):

   "The compiler is side-effect free and reentrant, and the semantics of
    loading a compiled file is the same as the semantics of loading the
    source, provided that all of the following are true:
       1) Only the standard functions are used to manipulate the
          package environment, and they are top-level forms in the
	  source.
       2) Eval-when is not used.
       3) All macros referenced by the source code are either defined
	  in the source code with a toplevel defmacro form before they
	  are used, or they are defined when the compiler is called.
       4) All macros used are side-effect free and reentrant."

You said:

  "To the extent which it matters, the package environment at the time
   the compiler interns a symbol must be equivalent to the package
   environment in which the loader interns the symbol."

What exactly did you mean by the phrase "to the extent which it
matters"?