From: Ben Goetter
Subject: Interleaving of compilation and execution environments
Date:
Message-ID: <8tvcv3$vfe$0@216.39.136.5>
Background: I'm trying to grok compile-time code generation in a Lisp
environment, but have hit a snag in understanding side effects at macro
expansion time.
Staring at the "Beyond the obvious, part 1" example in
http://psg.com/~dlamkins/sl/html/chapter20.html, I see something that I
don't quite follow. The example DEFVARs a hash table, then DEFMACROs a
macro that at expansion time first side-effects the table, then expands
into an AREF into a further reference into that table.
Are the CL compilation and execution environments so tightly interleaved
that the hash table's contents will truly persist at runtime? How
portable is this assumption? Sure, the pieces of the table that are
spliced into the macro's expansion will survive, since they're now part
of the program text, but the entire table?
Also, this example's compile-time initialization of the DEFVAR is
invalid, as I read CLtL2 25.1.3 and COMPILE-TIME-HANDLING-OF-TOP-LEVEL-
FORMS:CLARIFY.
Is my error in projecting compile-time behavior onto an example intended
for eval-time only, or is it more fundamental than that?
(Apologies if I've misread the example. I've spent some time in CLtL2
and the Hyperspec, but am not facile in CL. Obviously.)
Thanks for any enlightenment that you can share.
Ben
From: Barry Margolin
Subject: Re: Interleaving of compilation and execution environments
Date:
Message-ID: <tSGM5.61$wc4.617@burlma1-snr2>
In article <············@216.39.136.5>,
Ben Goetter <·······@mazama.net.xyz> wrote:
>Background: I'm trying to grok compile-time code generation in a Lisp
>environment, but have hit a snag in understanding side effects at macro
>expansion time.
>
>Staring at the "Beyond the obvious, part 1" example in
>http://psg.com/~dlamkins/sl/html/chapter20.html, I see something that I
>don't quite follow. The example DEFVARs a hash table, then DEFMACROs a
>macro that at expansion time first side-effects the table, then expands
>into an AREF into a further reference into that table.
>
>Are the CL compilation and execution environments so tightly interleaved
>that the hash table's contents will truly persist at runtime? How
>portable is this assumption? Sure, the pieces of the table that are
>spliced into the macro's expansion will survive, since they're now part
>of the program text, but the entire table?
If I understand the example correctly, the table doesn't need to persist at
runtime. At macro expansion time a particular entry is spliced into the
generated code, so only that needs to persist.
>Also, this example's compile-time initialization of the DEFVAR is
>invalid, as I read CLtL2 25.1.3 and COMPILE-TIME-HANDLING-OF-TOP-LEVEL-
>FORMS:CLARIFY.
>
>Is my error in projecting compile-time behavior onto an example intended
>for eval-time only, or is it more fundamental than that?
I believe you're correct. It should be wrapped in an (EVAL-WHEN
(:COMPILE-TOPLEVEL) ...). It should work when the forms are typed into a
Lisp evaluator, but if you compile it as a file it might not work properly.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, 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.
From: Kent M Pitman
Subject: Re: Interleaving of compilation and execution environments
Date:
Message-ID: <sfw1ywsa195.fsf@world.std.com>
Barry Margolin <······@genuity.net> writes:
> If I understand the example correctly, the table doesn't need to persist at
> runtime. At macro expansion time a particular entry is spliced into the
> generated code, so only that needs to persist.
I'm not looking at the example, but the normal cure if the assumption Barry
mentions doesn't hold is just to use compile-time-too mode, so the table
would be redundantly recreated at load time, so that it wouldn't need to
persist--it would just be recreated anew later with the same characteristics.
From: Ben Goetter
Subject: Re: Interleaving of compilation and execution environments
Date:
Message-ID: <8u27ch$jng$0@216.39.136.5>
No, the table doesn't need to persist at runtime. There's a comment in
the accompanying text <<Only one table will ever be generated for a given
value of divisions in the macro call.>> that led me into the Dark Wood of
Error, suggesting to me that the macro expansions would somehow share
single instances of those tables. As written, I don't think it will
share them, unless the compiler can coalesce similar arrays of flonums.
Thanks.