172 lines
11 KiB
HTML
172 lines
11 KiB
HTML
<!-- Common Lisp HyperSpec (TM), version 7.0 generated by Kent M. Pitman on Mon, 11-Apr-2005 2:31am EDT -->
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>CLHS: Issue DEFINING-MACROS-NON-TOP-LEVEL Writeup</TITLE>
|
|
<LINK HREF="../Data/clhs.css" REL="stylesheet" TYPE="text/css" />
|
|
<META HTTP-EQUIV="Author" CONTENT="Kent M. Pitman">
|
|
<META HTTP-EQUIV="Organization" CONTENT="LispWorks Ltd.">
|
|
<LINK REL=TOP HREF="../Front/index.htm">
|
|
<LINK REL=COPYRIGHT HREF="../Front/Help.htm#Legal">
|
|
<LINK REL=DISCLAIMER HREF="../Front/Help.htm#Disclaimer">
|
|
<LINK REL=PREV HREF="../Issues/iss103_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss104.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss105_w.htm">
|
|
</HEAD>
|
|
<BODY>
|
|
<H1><A REV=MADE HREF="http://www.lispworks.com/"><IMG WIDTH=80 HEIGHT=65 ALT="[LISPWORKS]" SRC="../Graphics/LWSmall.gif" ALIGN=Bottom></A><A REL=TOP HREF="../Front/index.htm"><IMG WIDTH=237 HEIGHT=65 ALT="[Common Lisp HyperSpec (TM)]" SRC="../Graphics/CLHS_Sm.gif" ALIGN=Bottom></A> <A REL=PREV HREF="../Issues/iss103_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss104.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss105_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue DEFINING-MACROS-NON-TOP-LEVEL Writeup</H2>
|
|
|
|
<PRE><B>Forum:</B> Compiler<P>
|
|
<B>Issue:</B> <A HREF="iss104.htm">DEFINING-MACROS-NON-TOP-LEVEL</A><P>
|
|
<B>References:</B> CLtL p. 66-70, 114, 143<P>
|
|
Issue <A HREF="iss147.htm">EVAL-WHEN-NON-TOP-LEVEL</A><P>
|
|
Issue <A HREF="iss059.htm">COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS</A><P>
|
|
Issue <A HREF="iss066.htm">COMPILER-LET-CONFUSION</A><P>
|
|
<B>Category:</B> CLARIFICATION, ENHANCEMENT, CHANGE<P>
|
|
<B>Edit History:</B> 6-May-88, V1 by Sandra Loosemore<P>
|
|
9-Jun-88, V2 by Sandra Loosemore<P>
|
|
12-Sep-88, V3 by Sandra Loosemore (fix garbled section 4)<P>
|
|
21-Sep-88, V4 by Sandra Loosemore (clarify section 5)<P>
|
|
16-Dec-88, V5 by Sandra Loosemore (major restructuring)<P>
|
|
31-Dec-88, V6 by Sandra Loosemore (wording clarifications)<P>
|
|
07-Jan-89, V7 by Sandra Loosemore (add example)<P>
|
|
09-Mar-89, V8 by Sandra Loosemore (more restructuring)<P>
|
|
22-Mar-89, V9 by Sandra Loosemore (add <A REL=DEFINITION HREF="../Body/s_flet_.htm#macrolet"><B>MACROLET</B></A> stuff)<P>
|
|
<B>Status:</B> Ready for release<P>
|
|
<P>
|
|
<P>
|
|
<B>Problem Description:<P>
|
|
</B><P>
|
|
CLtL leaves the interpretation of defining forms such as <A REL=DEFINITION HREF="../Body/m_defmac.htm#defmacro"><B>DEFMACRO</B></A> and<P>
|
|
<A REL=DEFINITION HREF="../Body/m_defpar.htm#defvar"><B>DEFVAR</B></A> that appear in other than top-level locations unclear.<P>
|
|
<P>
|
|
On page 66, it is stated: "It is not illegal to use these forms at<P>
|
|
other than top level, but whether it is meaningful to do so depends on<P>
|
|
context. Compilers, for example, may not recognize these forms<P>
|
|
properly in other than top-level contexts". At least one implementation <P>
|
|
has interpreted this to mean that it is permissible to simply refuse<P>
|
|
to compile defining macros that do not appear at top-level.<P>
|
|
<P>
|
|
A further problem is that CLtL p. 145 states that macro functions are<P>
|
|
always defined in the null lexical environment. These semantics would<P>
|
|
<A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A> it to be a special form, not a macro, since there is no<P>
|
|
possible macro expansion that has equivalent semantics under the<P>
|
|
processing model presented in issue <A HREF="iss147.htm">EVAL-WHEN-NON-TOP-LEVEL</A>. Under<P>
|
|
that model, it ought to be possible for <A REL=DEFINITION HREF="../Body/m_defmac.htm#defmacro"><B>DEFMACRO</B></A> to be implemented as<P>
|
|
expanding into an <A REL=DEFINITION HREF="../Body/s_eval_w.htm#eval-when"><B>EVAL-WHEN</B></A>. Furthermore, the macro function should<P>
|
|
appear in a for-evaluation position in the expansion, such as<P>
|
|
(function (<A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>lambda</B></A> ...)).<P>
|
|
<P>
|
|
<P>
|
|
<B>Proposal DEFINING-MACROS-NON-TOP-LEVEL:ALLOW:<P>
|
|
</B><P>
|
|
(1) Remove the language from p. 66 of CLtL quoted above. Clarify that<P>
|
|
while defining macros normally appear at top level, it is meaningful<P>
|
|
to place them in non-top-level contexts and that the compiler must<P>
|
|
handle them properly in all situations. However, the compile-time side<P>
|
|
effects described in issue <A HREF="iss059.htm">COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS</A> <P>
|
|
only take place when the defining macros appear at top-level.<P>
|
|
<P>
|
|
(2) Remove the language from p. 145 of CLtL referenced above. Clarify<P>
|
|
that all defining macros which create functional objects (including<P>
|
|
<A REL=DEFINITION HREF="../Body/m_defmac.htm#defmacro"><B>DEFMACRO</B></A>, <A REL=DEFINITION HREF="../Body/m_deftp.htm#deftype"><B>DEFTYPE</B></A>, DEFINE-SETF-METHOD, and the complex form of<P>
|
|
<A REL=DEFINITION HREF="../Body/m_defset.htm#defsetf"><B>DEFSETF</B></A>, as well as <A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>DEFUN</B></A>) must ensure that those functions are<P>
|
|
defined in the lexical environment in which the defining form appears.<P>
|
|
<P>
|
|
(3) Change the description of <A REL=DEFINITION HREF="../Body/s_flet_.htm#macrolet"><B>MACROLET</B></A> to indicate that the macro<P>
|
|
functions it creates are defined in the lexical environment in which<P>
|
|
the <A REL=DEFINITION HREF="../Body/s_flet_.htm#macrolet"><B>MACROLET</B></A> form appears, and not the null lexical environment.<P>
|
|
State that declarations and <A REL=DEFINITION HREF="../Body/s_flet_.htm#macrolet"><B>MACROLET</B></A> and <A REL=DEFINITION HREF="../Body/s_symbol.htm#symbol-macrolet"><B>SYMBOL-MACROLET</B></A> definitions<P>
|
|
affect the local macro definitions in a <A REL=DEFINITION HREF="../Body/s_flet_.htm#macrolet"><B>MACROLET</B></A>, but that the<P>
|
|
consequences are undefined if the local macro definitions reference<P>
|
|
any local variable or function bindings that are visible in that<P>
|
|
lexical environment.<P>
|
|
<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
Items (1) and (2) make the rules for when defining macros cause<P>
|
|
compile-time side effects to be exactly the same as the rules for when<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_eval_w.htm#eval-when"><B>EVAL-WHEN</B></A> (<A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A>) ...) causes compile-time evaluation. This<P>
|
|
provides a simple implementation technique.<P>
|
|
<P>
|
|
Item (3) makes the handling of <A REL=DEFINITION HREF="../Body/s_flet_.htm#macrolet"><B>MACROLET</B></A> macro definitions consistent<P>
|
|
with <A REL=DEFINITION HREF="../Body/m_defmac.htm#defmacro"><B>DEFMACRO</B></A> macro definitions.<P>
|
|
<P>
|
|
<P>
|
|
<B>Current Practice:<P>
|
|
</B><P>
|
|
Most implementations do allow defining macros in non-top-level places.<P>
|
|
However, the rules for when they cause compile-time side-effects are<P>
|
|
not always the same as those for <A REL=DEFINITION HREF="../Body/s_eval_w.htm#eval-when"><B>EVAL-WHEN</B></A>. This is the case in<P>
|
|
Lucid Common Lisp, for example.<P>
|
|
<P>
|
|
Lucid evaluates <A REL=DEFINITION HREF="../Body/m_defmac.htm#defmacro"><B>DEFMACRO</B></A> macro functions in the lexical environment<P>
|
|
in which the <A REL=DEFINITION HREF="../Body/m_defmac.htm#defmacro"><B>DEFMACRO</B></A> appears, but always evaluates <A REL=DEFINITION HREF="../Body/s_flet_.htm#macrolet"><B>MACROLET</B></A> macro<P>
|
|
functions in the null lexical environment.<P>
|
|
<P>
|
|
<P>
|
|
<B>Cost to implementors:<P>
|
|
</B><P>
|
|
Implementations that currently don't compile defining macros correctly<P>
|
|
when they appear at non-top-level will have to be changed.<P>
|
|
<P>
|
|
There will also be changes required to support compile-time definition<P>
|
|
of functions in a non-null lexical environment. These changes<P>
|
|
are required to support defining macros such as DEFINE-SETF-METHOD<P>
|
|
that <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A> functional objects to be created at compile-time, as well<P>
|
|
as to support the changes to <A REL=DEFINITION HREF="../Body/m_defmac.htm#defmacro"><B>DEFMACRO</B></A> and <A REL=DEFINITION HREF="../Body/s_flet_.htm#macrolet"><B>MACROLET</B></A>. (Note that even<P>
|
|
though defining macros cause compile-time evaluation only at<P>
|
|
top-level, top-levelness does not necessarily imply a null lexical<P>
|
|
environment under proposal EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL.)<P>
|
|
<P>
|
|
<P>
|
|
<B>Cost to users:<P>
|
|
</B><P>
|
|
The changes to <A REL=DEFINITION HREF="../Body/m_defmac.htm#defmacro"><B>DEFMACRO</B></A> and the other defining macros probably will<P>
|
|
cause few problems for users. Since CLtL didn't <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A> non-top-level<P>
|
|
defining macros to be meaningful, assigning them a meaning is a<P>
|
|
compatible extension.<P>
|
|
<P>
|
|
The changes to <A REL=DEFINITION HREF="../Body/s_flet_.htm#macrolet"><B>MACROLET</B></A> may cause problems for users who have assumed<P>
|
|
that, within local macro definitions, global function and variable<P>
|
|
definitions are not shadowed by local function and variable bindings.<P>
|
|
Code-walking programs will also have to be changed to reflect the new<P>
|
|
semantics (see issue <A HREF="iss342.htm">SYNTACTIC-ENVIRONMENT-ACCESS</A>).<P>
|
|
<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
The notion of defining macros as being somehow special when they<P>
|
|
appear at top-level is removed, since their behavior can be explained<P>
|
|
using <A REL=DEFINITION HREF="../Body/s_eval_w.htm#eval-when"><B>EVAL-WHEN</B></A> as a primitive. Allowing defining macros to appear<P>
|
|
anywhere instead of restricting them to certain positions results in a<P>
|
|
cleaner language design.<P>
|
|
<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
This proposal is consistent with the behavior specified in proposal<P>
|
|
EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL. In particular, if the compile<P>
|
|
time side-effects for defining macros specified in proposal<P>
|
|
<A HREF="iss059.htm">COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY</A> are implemented using<P>
|
|
<A REL=DEFINITION HREF="../Body/s_eval_w.htm#eval-when"><B>EVAL-WHEN</B></A>, the "right" compiler behavior for defining macros at<P>
|
|
non-top-level will happen automatically.<P>
|
|
<P>
|
|
The problems with compile-time definition of functions in a non-null<P>
|
|
environment could be avoided by modifying proposal<P>
|
|
<A HREF="iss104.htm">DEFINING-MACROS-NON-TOP-LEVEL</A> to remove the special treatment for<P>
|
|
<A REL=DEFINITION HREF="../Body/s_flet_.htm#macrolet"><B>MACROLET</B></A>, <A REL=DEFINITION HREF="../Body/s_symbol.htm#symbol-macrolet"><B>SYMBOL-MACROLET</B></A>, and <A REL=DEFINITION HREF="../Body/s_locall.htm#locally"><B>LOCALLY</B></A>.<P>
|
|
</PRE>
|
|
<HR>
|
|
|
|
<A REL=NAVIGATOR HREF="../Front/StartPts.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Starting Points]" SRC="../Graphics/StartPts.gif" ALIGN=Bottom></A><A REL=TOC HREF="../Front/Contents.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Contents]" SRC="../Graphics/Contents.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Master.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Index]" SRC="../Graphics/Index.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Symbol.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Symbols]" SRC="../Graphics/Symbols.gif" ALIGN=Bottom></A><A REL=GLOSSARY HREF="../Body/26_a.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Glossary]" SRC="../Graphics/Glossary.gif" ALIGN=Bottom></A><A HREF="../Front/X3J13Iss.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Issues]" SRC="../Graphics/Issues.gif" ALIGN=Bottom></A><BR>
|
|
|
|
<A REL=COPYRIGHT HREF="../Front/Help.htm#Legal"><I>Copyright 1996-2005, LispWorks Ltd. All rights reserved.</I></A><P>
|
|
</BODY>
|
|
</HTML>
|