Remembering information during compilation
in [Lisp]
|
Prev: Lisp sucks!
Next: grabbing key presses
From: Spiros Bousbouras on 20 Nov 2009 12:11 On 20 Nov, 12:40, Spiros Bousbouras <spi...(a)gmail.com> wrote: > And yes , I know it uses side effects but I'm not convinced > this is something worrying about. something worth worrying about.
From: Spiros Bousbouras on 21 Nov 2009 03:38 On 18 Nov, 22:51, "Tobias C. Rittweiler" <t...(a)freebits.de.invalid> wrote: > Spiros Bousbouras <spi...(a)gmail.com> writes: > > On 17 Nov, 18:01, "Tobias C. Rittweiler" wrote: > > > > Do you know that it can in fact lead to an _impairment_ of runtime speed > > > because implementation which would previously implement some macros as > > > special forms cannot do so? > > > No I didn't know it. Can you give me an example of something an > > implementation can do without MACROEXPAND-ALL that it couldn't do if > > MACROEXPAND-ALL existed ? > > Say your implementation implements DOLIST as a special form[*] for > reasons of efficiency. In case of > > (defun foo (list &aux (sum 0)) (dolist (i list sum) (incf sum i))) > > the implementation can process DOLIST as a special form. > > Contrarily on: > > (defmacro walk-at-compile-time (form &environment env) > (macroexpand-all form env)) > > (defun bar (list &aux (sum 0)) > (walk-at-compile-time (dolist (i list sum) (incf sum i)))) > > the implementation has to expand the DOLIST form into something probably > involving TAGBODY. We assumed that the implementation as special form > would be more efficient -- so this shows how code-walking can impose > runtime penalty. I don't see why macroexpand-all cannot just return the dolist form itself if dolist is implemented as a special form. It would be perfectly adequate for the purpose I stated in my OP. As a debugging tool it might even be preferable if macroexpand-all did not continue the expansion beyond objects defined in the Lisp standard. So if I have something like (my-macro1 arg1 (my-macro2 args)) and want to examine that it does the right thing it would be more useful if (macroexpand-all '(my-macro1 arg1 (my-macro2 args))) only expanded my macros but not things like do , dolist etc. And while we're at it , in an implementation where dolist is a special form what are the return values of (macroexpand '(dolist ...)) ? -- Always remember that it is impossible to speak in such a way that you cannot be misunderstood: there will always be some who misunderstand you. Sir Karl Popper
From: Pascal J. Bourguignon on 21 Nov 2009 05:13 Spiros Bousbouras <spibou(a)gmail.com> writes: > I don't see why macroexpand-all cannot just return the dolist form > itself if dolist is implemented as a special form. Because section "3.1.2.1.2.2 Macro Forms" says so. DOLIST is specified to be a macro and as mentionned by section "3.1.2.1.2.2 Macro Forms": An implementation is free to implement a Common Lisp special operator as a macro. An implementation is free to implement any macro operator as a special operator, but only if an equivalent definition of the macro is also provided. it can be implemented as a special operator, however, in that case the implementation must provide a macro definition expanding (eventually) only to standard special operators, for the benefit of code walkers. -- __Pascal Bourguignon__
From: Spiros Bousbouras on 21 Nov 2009 06:24 On 21 Nov, 10:13, p...(a)informatimago.com (Pascal J. Bourguignon) wrote: > Spiros Bousbouras <spi...(a)gmail.com> writes: > > I don't see why macroexpand-all cannot just return the dolist form > > itself if dolist is implemented as a special form. > > Because section "3.1.2.1.2.2 Macro Forms" says so. > > DOLIST is specified to be a macro and as mentionned by section > "3.1.2.1.2.2 Macro Forms": > > An implementation is free to implement a Common Lisp special > operator as a macro. An implementation is free to implement any > macro operator as a special operator, but only if an equivalent > definition of the macro is also provided. > > it can be implemented as a special operator, however, in that case the > implementation must provide a macro definition expanding (eventually) > only to standard special operators, for the benefit of code walkers. But the standard does not mention macroexpand-all so it can behave any way it likes. Furthermore it's not unreasonable that it would not expand something which the implementation offers as a special form even if the standard says is a macro. Or macroexpand-all could be designed to take an additional argument by which the programmer can switch between "expand everything the standard says is a macro" and "expand everything that this implementation actually (only) implements as a macro". But more to the point earlier in the thread Tobias said: How does MACROEXPAND-ALL help the speed of compilation? Using it, the implementation has to walk the syntax tree twice. Do you know that it can in fact lead to an _impairment_ of runtime speed because implementation which would previously implement some macros as special forms cannot do so? Even now as I reread it it seems to be saying that just by making available macroexpand-all an implementation is prevented from implementing some macros as special forms. But I think what he meant was that if a piece of code uses macroexpand-all then when compiling this code an implementation can no longer use the special form version of a macro (if it has one) and has to use instead the actual macro expansion. So yes , I see how macroexpand-all can cause an impairment of *runtime* speed even when it is only called during compilation. But this could be solved by offering a switch as I mention above. -- Never attribute to conspiracy what can adequately be explained by shared attitudes.
From: Pascal J. Bourguignon on 21 Nov 2009 07:10
Spiros Bousbouras <spibou(a)gmail.com> writes: > On 21 Nov, 10:13, p...(a)informatimago.com (Pascal J. Bourguignon) > wrote: >> Spiros Bousbouras <spi...(a)gmail.com> writes: >> > I don't see why macroexpand-all cannot just return the dolist form >> > itself if dolist is implemented as a special form. >> >> Because section "3.1.2.1.2.2 Macro Forms" says so. >> >> DOLIST is specified to be a macro and as mentionned by section >> "3.1.2.1.2.2 Macro Forms": >> >> An implementation is free to implement a Common Lisp special >> operator as a macro. An implementation is free to implement any >> macro operator as a special operator, but only if an equivalent >> definition of the macro is also provided. >> >> it can be implemented as a special operator, however, in that case the >> implementation must provide a macro definition expanding (eventually) >> only to standard special operators, for the benefit of code walkers. > > But the standard does not mention macroexpand-all so it can behave > any way it likes. Right, macroexpand-all is not a Common Lisp function. My bad, sorry. What I said applies only to CL:MACROEXPAND-1 and CL:MACROEXPAND. > Furthermore it's not unreasonable that it would not > expand something which the implementation offers as a special form > even if the standard says is a macro. Or macroexpand-all could be > designed to take an additional argument by which the programmer can > switch between "expand everything the standard says is a macro" and > "expand everything that this implementation actually (only) > implements as a macro". > > But more to the point earlier in the thread Tobias said: > > How does MACROEXPAND-ALL help the speed of compilation? Using > it, the implementation has to walk the syntax tree twice. > > Do you know that it can in fact lead to an _impairment_ of > runtime speed because implementation which would previously > implement some macros as special forms cannot do so? > > Even now as I reread it it seems to be saying that just by making > available macroexpand-all an implementation is prevented from > implementing some macros as special forms. But I think what he meant > was that if a piece of code uses macroexpand-all then when compiling > this code an implementation can no longer use the special form > version of a macro (if it has one) and has to use instead the actual > macro expansion. So yes , I see how macroexpand-all can cause an > impairment of *runtime* speed even when it is only called during > compilation. But this could be solved by offering a switch as I > mention above. Clearly, the expectation of na�ve users such as me about a macroexpand-all function would be that it expands to the same special operators as macroexpand or macroexpand-1. I'd say that expanding to the special operators of the implementation is a specific need, and would need a more specific function, such as EXPAND-ALL-TO-IMPLEMENTATION-SPECIAL-OPERATORS. -- __Pascal Bourguignon__ |