In incremental compiling, when the definition of a macro changes, how
does one manage to get all the mentions of the macro (which were
already expanded with the old macro definition) reexpanded? What are
the caveats, pitfalls and gotchas?
(convey (regards 'Haroldo) ('thanks))
Haroldo Stenger wrote:
> In incremental compiling, when the definition of a macro changes, how
> does one manage to get all the mentions of the macro (which were
> already expanded with the old macro definition) reexpanded? What are
> the caveats, pitfalls and gotchas?
Macros are required to be expanded before runtime only when the code is
compiled. (See the section on minimal compilation in the HyperSpec.)
When the code is interpreted, it is likely that macros will be
reexpanded on each use. So it is reasonable to use an interpreter during
development.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Hi Pascal, thanks, please see my comment below.
Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
> Macros are required to be expanded before runtime only when the code is
> compiled. (See the section on minimal compilation in the HyperSpec.)
> When the code is interpreted, it is likely that macros will be
> reexpanded on each use. So it is reasonable to use an interpreter during
> development.
I understand. Two questions arose to the surface of my head now:
1) An interpreter, is any special known name of Common Lisp
implementations? or is it a *mode* of operation of any Common Lisp
implementation?
2) When in development, I have come to appreciate incremental
compiling as the best and preferred method, and one of the advantages
of CL environments. Not to enter in a senseless discussion of "what is
the best", why or when would you prefer an interpreter over an
incremental compiler?
Thank you.
Haroldo
········@adinet.com.uy (Haroldo Stenger) writes:
> Hi Pascal, thanks, please see my comment below.
>
> Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
> > Macros are required to be expanded before runtime only when the code is
> > compiled. (See the section on minimal compilation in the HyperSpec.)
> > When the code is interpreted, it is likely that macros will be
> > reexpanded on each use. So it is reasonable to use an interpreter during
> > development.
>
> I understand. Two questions arose to the surface of my head now:
>
> 1) An interpreter, is any special known name of Common Lisp
> implementations? or is it a *mode* of operation of any Common Lisp
> implementation?
It is, more or less, a mode of certain implementations. Some Lisp may
create an interpreted function when you type the defun form directly
in the REPL or eval it in an editor buffer, for example - but they
don't have to. Some implementations - AFAIK Corman and SBCL are among
them - do not even have an interpreter, and always compile to native
code on the fly.
This is made even more confusing by the slightly non-intuitive meaning
of "compiled" in the ANSI standard, which does not neccessarily mean
"compiled to native code" (or bytecode). For example, CMUCL has an
interpreter in the conventional sense, and an interactively defined
function will be interpreted, but it is a "compiled function" in the
ANSI CL sense, i.e. all macros and compiler-macros are expanded and it
doesn't refer to unresolved load-time values.
CL-USER> (defun foo () :foo)
FOO
CL-USER> (type-of #'foo)
EVAL:INTERPRETED-FUNCTION
CL-USER> (compiled-function-p #'foo)
T
As Pascal said, it would be a good idea to read the Compilation
Semantics section (3.2.2, <http://www.lispworks.com/reference/HyperSpec/Body/03_bb.htm>)
of the Spec, especially 3.2.2.2 Minimal Compilation.
Whether and how it is possible to create interpreted functions that
don't have to be redefined should a macro they use change is pretty
implementation dependent, so it might be a good idea to tell us which
one you use.
> 2) When in development, I have come to appreciate incremental
> compiling as the best and preferred method, and one of the advantages
> of CL environments. Not to enter in a senseless discussion of "what is
> the best", why or when would you prefer an interpreter over an
> incremental compiler?
I don't think this is much of a difference from a workflow point of
view, but I'm not sure if I understand fully what you mean by
"incremental compilation".
Henrik Motakef <············@henrik-motakef.de> writes:
> For example, CMUCL has an interpreter in the conventional sense,
> and an interactively defined function will be interpreted, but it
> is a "compiled function" in the ANSI CL sense, i.e. all macros and
> compiler-macros are expanded and it doesn't refer to unresolved
> load-time values.
In the version I have here (18e-6 from Debian):
(defun foo () (bar) (load-time-value (baz)))
FOO
* (compiled-function-p #'foo)
T
* (defmacro bar () '(print "too late"))
BAR
* (defun baz () 42)
BAZ
* (foo)
"too late"
42
*
So, FOO had both a reference to an undefined macro and an unresolved
load-time value, yet COMPILED-FUNCTION-P returned true. Indeed, in
target:code/type.lisp:
(deftype compiled-function () 'function)
And in target:compiler/generic/vm-tran.lisp:
(def-source-transform compiled-function-p (x)
`(functionp ,x))
Is this working correctly?
Kalle Olavi Niemitalo wrote:
> In the version I have here (18e-6 from Debian):
Now that's a *really* small version number :-).
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <················@pobox.com> writes:
> Kalle Olavi Niemitalo wrote:
>
>> In the version I have here (18e-6 from Debian):
>
> Now that's a *really* small version number :-).
Interestingly enough, it's the version that comes after 18e-5...
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Haroldo Stenger wrote:
> Hi Pascal, thanks, please see my comment below.
>
> Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
>
>>Macros are required to be expanded before runtime only when the code is
>>compiled. (See the section on minimal compilation in the HyperSpec.)
>>When the code is interpreted, it is likely that macros will be
>>reexpanded on each use. So it is reasonable to use an interpreter during
>>development.
>
>
> I understand. Two questions arose to the surface of my head now:
>
> 1) An interpreter, is any special known name of Common Lisp
> implementations? or is it a *mode* of operation of any Common Lisp
> implementation?
>
> 2) When in development, I have come to appreciate incremental
> compiling as the best and preferred method, and one of the advantages
> of CL environments. Not to enter in a senseless discussion of "what is
> the best", why or when would you prefer an interpreter over an
> incremental compiler?
Hm, maybe it would benefit the discussion if you explained what problem
you actually have wrt macro expansion.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
> Hm, maybe it would benefit the discussion if you explained what problem
> you actually have wrt macro expansion.
Well, I'm just trying to harvest different development styles that
people use. I wasn't in fact worried about this issue (macro re
expansion) until I was having an irc discussion where I was very
enthusiastic about using macros to build big abstractions, and someone
told that they could result uncomfortable in an incremental compiling
envorinment. I think we were talking about CMUCL or SBCL, not sure.
I think the dependency system approach is the best, but got also
interested in your suggestion.
Haroldo
········@adinet.com.uy (Haroldo Stenger) writes:
> Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
> > Hm, maybe it would benefit the discussion if you explained what problem
> > you actually have wrt macro expansion.
>
> Well, I'm just trying to harvest different development styles that
> people use. I wasn't in fact worried about this issue (macro re
> expansion) until I was having an irc discussion where I was very
> enthusiastic about using macros to build big abstractions, and someone
> told that they could result uncomfortable in an incremental compiling
> envorinment. I think we were talking about CMUCL or SBCL, not sure.
Once in a while, you can get yourself into a really confusing
situation by having forgotten to reexpand calls to a macro that you
redefined. When I come across a truly puzzling bug, I usually rebuild
the system before banging my head against the wall -- if that doesn't
solve it, at least I don't have to carry the nagging feeling that I
might be debugging an image that doesn't correspond to the current
source.
Actually, I haven't gotten myself into one of those binds in a while.
I used to run Lisp images for weeks or months at a time, evaluating
individual forms from source files with abandon. Nowadays, I'll
recompile and load an entire file when I feel done with it, at least
for the moment. And every week I start up a fresh Lisp and rebuild
the system. It would be nice to utilize a who-macroexpands database
on macro redefinition, tho.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Thomas F. Burdick" <···@famine.OCF.Berkeley.EDU> wrote in message
····················@famine.OCF.Berkeley.EDU...
> Actually, I haven't gotten myself into one of those binds in a while.
> I used to run Lisp images for weeks or months at a time, evaluating
> individual forms from source files with abandon. Nowadays, I'll
> recompile and load an entire file when I feel done with it, at least
> for the moment. And every week I start up a fresh Lisp and rebuild
> the system. It would be nice to utilize a who-macroexpands database
> on macro redefinition, tho.
Of course, if you use LispWorks eval edition, it shuts down after about 4
hours anyway, so any strange problems you have regarding macro versioning
will certainly be gone within 4 hours anyway :-).
Regards,
Will Hartung
(·····@msoft.com)
Haroldo Stenger wrote:
> Well, I'm just trying to harvest different development styles that
> people use. I wasn't in fact worried about this issue (macro re
> expansion) until I was having an irc discussion where I was very
> enthusiastic about using macros to build big abstractions, and someone
> told that they could result uncomfortable in an incremental compiling
> envorinment. I think we were talking about CMUCL or SBCL, not sure.
>
Late response. Yeah, it is a total pain. But at the level of minor, very
rare irritant. Certainly not rsing anywhere near the level where it
should be a consideration in a discussion about the worth of macros.
One problem for me is that my project manager of choice does not allow
me to declare inter-source dependencies, otherwise I could drop all my
macros in one or two places and make sure... well, to be honest, systems
are so fast now a full build from scratch of even a big project takes a
negligible amount of time /if/ I am really worried about it, and usually
I am not... I am making a change to fix one usage, which will get
recompiled at the same time because I am changing it in other ways, and
the other guys will get recompiled at some point, but they already work
so there is no hurry.
One exception is a killer macro under development but already propagated
out to a half-dozen source files. A practice I learned from the Old
Hands was (and sorry if this has already been covered):
(defmacro with-killer-macro <astonishing argument list &body body>
`(call-with-killer-macro ... ... ... (lambda (it) ,@body)))
(defun call-with-killer-macro (.. ... .. .. macro-body-func)
....)
Now I can change the killer function at will and all the different
invocations of the macro lead to the new processing.
kt
--
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"[If anyone really has healing powers,] I would like to call
them about my knees."
-- Tenzin Gyatso, the Fourteenth Dalai Lama
Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
> Hm, maybe it would benefit the discussion if you explained what problem
> you actually have wrt macro expansion.
I don't know where to put this link
http://www.cs.utah.edu/plt/publications/macromod.pdf
fit, but a follow up to your message seems good :-)
It's mostly about MzScheme but it's claimed to have considerations
about Common Lisp.
If anyone wants to continue the analysis or to debunk anything please
feel free.
Haroldo
Pascal Costanza wrote:
>
> Haroldo Stenger wrote:
>
>> In incremental compiling, when the definition of a macro changes, how
>> does one manage to get all the mentions of the macro (which were
>> already expanded with the old macro definition) reexpanded? What are
>> the caveats, pitfalls and gotchas?
>
>
> Macros are required to be expanded before runtime only when the code is
> compiled. (See the section on minimal compilation in the HyperSpec.)
> When the code is interpreted, it is likely that macros will be
> reexpanded on each use. So it is reasonable to use an interpreter during
> development.
I think it would be a serious mistake to use an interpreter to make sure
functions containing macro definitions always see the latest version of
the macro. For one thing, as Henrik Motakef pointed out, what an
interpreter does is not well defined. For another, if an interpreter
actually did continually re-expand macros, a macro call in an inner loop
would cost a lot. Of course, running interpreted rather than compiled
already costs a factor of k, but with macros inside macros it could
become exponential.
Don't use the "interpreter," if there is one, for anything serious.
Compile everything and, if a macro changes, compile it again.
Fortunately, if a project is at a stage where macros are continually
changing, probably everything else is continually changing, too, so this
isn't much of a hardship.
-- Drew McDermott
········@adinet.com.uy (Haroldo Stenger) writes:
> In incremental compiling, when the definition of a macro changes, how
> does one manage to get all the mentions of the macro (which were
> already expanded with the old macro definition) reexpanded?
By using a system definition library and carefully declaring such
dependencies.
Of course, having a WHO-MACROEXPANDS function in the CMUCL XREF
package is also nice...
"Haroldo Stenger" <········@adinet.com.uy> wrote in message
·································@posting.google.com...
> In incremental compiling, when the definition of a macro changes, how
> does one manage to get all the mentions of the macro (which were
> already expanded with the old macro definition) reexpanded? What are
> the caveats, pitfalls and gotchas?
You have to redefine any functions that use your modified macro if you want
them to change. This is not necessarily the case with interpreted functions
(ie playing around at top level), but it is with compiled functions.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
>>>>> "hs" == Haroldo Stenger <········@adinet.com.uy> writes:
>>>>> "hm" == Henrik Motakef <············@henrik-motakef.de> writes:
hs> In incremental compiling, when the definition of a macro changes, how
hs> does one manage to get all the mentions of the macro (which were
hs> already expanded with the old macro definition) reexpanded? What are
hs> the caveats, pitfalls and gotchas?
hm> Of course, having a WHO-MACROEXPANDS function in the CMUCL XREF
hm> package is also nice...
indeed, that is an application of CMUCL's XREF facility that I would
like to work on one of these days: recompilation of all dependent
functions when a macro is redefined. This would require a high debug
level so that the original source code remains available via
FUNCTION-LAMBDA-EXPRESSION, and for CMUCL's XREF facility to become a
little more reliable and polished than it currently is.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
From: Scott Determan
Subject: Re: Macro expansion triggered on change
Date:
Message-ID: <m3znbx9nj5.fsf@yahoo.com>
········@adinet.com.uy (Haroldo Stenger) writes:
> In incremental compiling, when the definition of a macro changes, how
> does one manage to get all the mentions of the macro (which were
> already expanded with the old macro definition) reexpanded? What are
> the caveats, pitfalls and gotchas?
>
> (convey (regards 'Haroldo) ('thanks))
Sorry to reply so late to this thread, but I thought I would add a
reference in case someone googles for this.
In the book "Advanced LISP Technology" edited by Taiichi Yuasa and
Hiroshi G. Okuno, 2002, there is an article titled: "Automatic
Recompilation on Macro Redefinition, by Making Use of Weak Conses".