I've read a few books on CLISP and I'm trying to get my head around macros
and how they work at a low level.
When does the expansion actually occur? And, from an implementation point
of view, does the macro get injected into the s-expression at the call site?
tia,
--
Justin Johnson
"Justin Johnson" <·······@mobiusent.com> wrote in message news:<··················@demeter.uk.clara.net>...
> I've read a few books on CLISP and I'm trying to get my head around macros
> and how they work at a low level.
On the CLISP implementation or Lisp? (I didn't know there were CLISP
books).
> When does the expansion actually occur?
It occurs at, ... drumroll ... macro expansion time!
:)
Macros are expanded sometime prior to when their expansion is needed.
This could be when the macro-using source code is loaded, when it is
compiled, or maybe it can happen as late as the point of evaluation of
the macro call.
A properly written macro works right in all these circumstances.
One implication of this is that when a macro refers to special
variables or functions, EVAL-WHEN forms have to be added to ensure
that the functions and variables will be available at expansion time.
> And, from an implementation point
> of view, does the macro get injected into the s-expression at the call site?
The expansion replaces the call.
···@ashi.footprints.net (Kaz Kylheku) writes:
[...]
> Macros are expanded sometime prior to when their expansion is needed.
> This could be when the macro-using source code is loaded, when it is
> compiled, or maybe it can happen as late as the point of evaluation of
> the macro call.
Well, there are some constraints, like the requirement that compilation
ensures all macroexpansions are completed, i.e. executing compiled code
will not involve macroexpansion.
[...]
> One implication of this is that when a macro refers to special
> variables or functions, EVAL-WHEN forms have to be added to ensure
> that the functions and variables will be available at expansion time.
`refers to' meaning `calls a function, evaluates a macro form, or obtains
the value of a special variable in order to _produce_ the macro expansion,
not in the code that is produced _by_ the macro expansion.' And EVAL-WHEN
is normally not necessary for things like ordinary top-level DEFUN and
DEFMACRO forms preceding the place where the file compiler would call the
macro function. (Not that I wrote a terribly precise paragraph, but I
hope you get the idea...)
> > And, from an implementation point
> > of view, does the macro get injected into the s-expression at the call site?
>
> The expansion replaces the call.
Meaning that the expansion `is evaluated in place of' the call^1,
but not that the original code can be destructively modified.
See issue SELF-MODIFYING-CODE:FORBID in the HyperSpec.
_________
^1 see the last sentence of the second paragraph of 3.1.2.1.2.2 Macro Forms
---Vassil.
> Meaning that the expansion `is evaluated in place of' the call^1,
> but not that the original code can be destructively modified.
> See issue SELF-MODIFYING-CODE:FORBID in the HyperSpec.
So, if an interpreter comes across a macro it evaluates this (like a
function) and then evaluates the return list?
Flexible, but isn't that kind of inefficient?
Perhaps there's some kind of caching going on behind the scenes...?
--
Justin Johnson
Justin Johnson wrote:
> So, if an interpreter comes across a macro it evaluates this (like a
> function) and then evaluates the return list?
>
> Flexible, but isn't that kind of inefficient?
If you want efficiency you compile.
Paul
* Justin Johnson wrote:
> So, if an interpreter comes across a macro it evaluates this (like a
> function) and then evaluates the return list?
Well, it calls the function that implements the macro, passing it the
macro source, and then uses whatever it returns instead,
> Flexible, but isn't that kind of inefficient?
> Perhaps there's some kind of caching going on behind the scenes...?
Well, interpreters may or may not cache, but typically the performance
of in interpreter is not something people stress about unduly. A
compiler on the other hand more-or-less `caches' by definition, since
macro expansion gets done as part of compilation, and therefore only
once.
--tim
In article <··················@demeter.uk.clara.net>,
Justin Johnson <·······@mobiusent.com> wrote:
>I've read a few books on CLISP and I'm trying to get my head around macros
>and how they work at a low level.
>
>When does the expansion actually occur?
If you compile a function or source file, the macros are expanded by the
compiler.
When you're interpreting a function, the macro is typically expanded each
time the expression is encountered. Note, however, that some
implementations don't actually have an interpreter; when you type or load
source code, it's compiled on the fly. So the macros may be expanded then.
> And, from an implementation point
>of view, does the macro get injected into the s-expression at the call site?
I'm not sure what this means. When a macro is invoked, it returns a new
s-expression, and this expression is compiled/interpreted in place of the
original.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.