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