On 7/31/07, Vladimir Sedach <vsedach@gmail.com> wrote:
> This might cause some unexpected behavior since it creates a lingering,
> universal compilation environment.  Package definitions will persist across
> all compilations, for example.

However, it turns out that in the code I'm working on, we do take
advantage of a persistent compilation environment in other ways
(specifically, I want macro definitions to persist across several
parenscript compilations),
 


Macro definitions specifically will always persist across many compilations.  Don't worry about making your macros persist as this will be transparent.

The way macro definitions work right now is by a global macro definition table that makes EQL lookups based on the symbol used as the macro name; these persist when a compilation environment is no longer in use.  There is a bug with this, however, since different packages may define a macro with the same name:

(in-package :paren-psos)

(defpsmacro defclass ...)

(in-package :other-class-system)

(defpsmacro defclass ..)

assuming both paren-psos and other-class-system use the CL package, DEFCLASS will be the same symbol (common-lisp::defclass).  the effective macro will then be whichever was last defined.  this is a bug.  the solution is to store macros in a multi-dimensional table by *package* at the time of macro definition and the symbol that names the macro.


so I've added a function
setup-persistent-compilation-environment to the deprecated file which
sets *compilation-environment* to such a value (and also a function to
clear *compilation-environment*).

I have no problem with that hack as we flesh out how compilation environments will be manipulated by the user.  Don't depend too much on it, however, as more advanced compilation features may require some environmental care.

Vladimir

Red