<br><br><div><span class="gmail_quote">On 7/31/07, <b class="gmail_sendername">Vladimir Sedach</b> <<a href="mailto:vsedach@gmail.com">vsedach@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> This might cause some unexpected behavior since it creates a lingering,<br>> universal compilation environment.  Package definitions will persist across<br>> all compilations, for example.<br><br>However, it turns out that in the code I'm working on, we do take
<br>advantage of a persistent compilation environment in other ways<br>(specifically, I want macro definitions to persist across several<br>parenscript compilations),</blockquote><div> </div><br><div><br>Macro definitions specifically will always persist across many compilations.  Don't worry about making your macros persist as this will be transparent.
<br><br>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:
<br><br>(in-package :paren-psos)<br><br>(defpsmacro defclass ...)<br><br>(in-package :other-class-system)<br><br>(defpsmacro defclass ..)<br><br>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.
<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> so I've added a function<br>setup-persistent-compilation-environment to the deprecated file which
<br>sets *compilation-environment* to such a value (and also a function to<br>clear *compilation-environment*).</blockquote><div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Vladimir</blockquote><div><br>Red<br></div></div>