nested macros
Erik Naggum
* sshte...@cctrading.com
| Note that the inner macro is not expanded [by macroexpand].
macroexpand only expands the one form it receives. any recursive expansion
would have to be performed by the caller as the form is descended, or by
the macro function explicitly (which is a very bad idea).
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://www.naggum.no/emacs/ for Emacs-20-related material.
Kent M Pitman
SDS <sshte...@cctrading.com> writes:
> (macroexpand '(sqr (sqr x)))
> ==> (let ((#:sqr17337 (sqr x))) (* #:sqr17337 #:sqr17337)) ; t
> Note that the inner macro is not expanded.
> Does this mean that it will be expanded at run-time?
> (in, say, (defun zz (x) (sqr (sqr x)))?)
Actually, if what you were worrying about was really a problem, you
should be even more worried because if you MACROEXPAND that DEFUN
you'll see it's expanded but NEITHER of the SQR forms inside it is. :-)
But the answer is that the compiler code-walks and compiles all your
code, not just the outermost form.
There happens to be no operator which expands all macros at all levels
of a form. I guess I don't have a strong idea whether that's good or
bad or what. What is your reason for asking? Are you just poking
around or do you have a specific need? There may be another way to
accomplish the need without it.
Raymond Toy
Marco Antoniotti <mar...@infiniti.path.berkeley.edu> writes:
> SDS <sshte...@cctrading.com> writes:
>
> >
> > >>>> In a very interesting message <sfwbu07...@world.std.com>
> > >>>> Sent on Thu, 30 Oct 1997 08:37:10 GMT
> > >>>> Honorable pit...@world.std.com (Kent M Pitman) writes
> > >>>> on the subject of "Re: nested macros":
> > >>
> > >> But the answer is that the compiler code-walks and compiles all your
> > >> code, not just the outermost form.
> >
> > so, I guess, it is safe (performance-wise) to call a macro from within a
> > macro.
>
> What's wrong with
>
> (defun sqr (x) (* x x))
>
> (declaim (inline sqr))
>
> ?
Because the compiler is free to ignore your declaim?
Ray
Marco Antoniotti
SDS <sshte...@cctrading.com> writes:
>
> >>>> In a very interesting message <sfwbu07...@world.std.com>
> >>>> Sent on Thu, 30 Oct 1997 08:37:10 GMT
> >>>> Honorable pit...@world.std.com (Kent M Pitman) writes
> >>>> on the subject of "Re: nested macros":
> >>
> >> But the answer is that the compiler code-walks and compiles all your
> >> code, not just the outermost form.
>
> so, I guess, it is safe (performance-wise) to call a macro from within a
> macro.
What's wrong with
(defun sqr (x) (* x x))
(declaim (inline sqr))
?
> >> What is your reason for asking? Are you just poking
> >> around or do you have a specific need? There may be another way to
> >> accomplish the need without it.
>
> I have my own macro which opens a file and does something else.
> I wondered whether I could use with-open-file there. I was pretty sure I
> could, but decided to check, and when I saw that macroexpand doesn't
> expand all the macros, I grew worried and posted the question.
>
What is missing from 'with-open-file' that makes you want to write a
new macro?
--
Marco Antoniotti
==============================================================================
California Path Program - UC Berkeley
Richmond Field Station
tel. +1 - 510 - 231 9472
Marco Antoniotti
Raymond Toy <*toy*@rtp.ericsson.se> writes:
>
> Marco Antoniotti <mar...@infiniti.path.berkeley.edu> writes:
>
> >
> > What's wrong with
> >
> > (defun sqr (x) (* x x))
> >
> > (declaim (inline sqr))
> >
> > ?
>
> Because the compiler is free to ignore your declaim?
>
Yep. However, "make it right, then make it fast" vouches for the
'inline' form.
Raymond Toy
SDS <sshte...@cctrading.com> writes:
> >>>> In a very interesting message <scfiuud...@infiniti.PATH.Berkeley.EDU>
> >>>> Sent on 31 Oct 1997 08:17:31 -0800
> >>>> Honorable Marco Antoniotti <mar...@infiniti.path.berkeley.edu> writes
> >>>> on the subject of "Re: nested macros":
> >>
> >> Raymond Toy <*toy*@rtp.ericsson.se> writes:
> >> > Marco Antoniotti <mar...@infiniti.path.berkeley.edu> writes:
> >> > > What's wrong with
> >> > > (defun sqr (x) (* x x))
> >> > > (declaim (inline sqr))
> >> > Because the compiler is free to ignore your declaim?
> >> Yep. However, "make it right, then make it fast" vouches for the
> >> 'inline' form.
>
> If "then" refers to priorities, you are right.
> I assume that "then" refers to timing, i.e., first make a working
> program, then optimize it. In the latter case, assuming that the program
> is already working and is being optimized for speed, the sqr macro would
> seem to be appropriate. Am I right?
I believe that's true on both counts: priorites and timing.
Note, as pointed out to me by Tim Bradshaw in a private mail, the
declaim has to come before the defun if you really want inline code.
Of the free Lisps, I think only CMUCL will actually inline your code.
Also, Tim mentions that Allegro does not support inline (maybe), Lucid does
(well did, since it's dead, but I guess that means Liquid, Harlequin's
Lucid probably does), and Genera does.
Be sure to profile your code before making making sqr into a macro. I
doubt, though, that inlining sqr via declaim or a macro will make much
difference in speed.
Ray
Raymond Toy
bern...@cli.di.unipi.it (Pierpaolo Bernardi) writes:
> Raymond Toy (*toy*@rtp.ericsson.se) wrote:
> [...]
>
> : Of the free Lisps, I think only CMUCL will actually inline your code.
>
> I think _all_ of the free Common Lisps do obey inline declarations
> (certainly Cmucl, Clisp and GCL do).
>
I stand corrected. Clisp does. However, it seems gcl does not, at
least not obviously. For this code:
(declaim (inline sqr))
(defun sqr (x)
(* x x))
(defun tst (x)
(sqr (sqr x)))
gcl produces this (edited) C file:
/* function definition for SQR */
static L1()
{register object *base=vs_base;
register object *sup=base+VM1; VC1
vs_check;
{object V1;
V1=(base[0]);
vs_top=sup;
TTL:;
base[1]= number_times((V1),(V1));
vs_top=(vs_base=base+1)+1;
return;
}
}
/* function definition for TST */
static L2()
{register object *base=vs_base;
register object *sup=base+VM2; VC2
vs_check;
{object V2;
V2=(base[0]);
vs_top=sup;
TTL:;
base[2]= (V2);
vs_top=(vs_base=base+2)+1;
(void) (*Lnk0)();
vs_top=sup;
base[1]= vs_base[0];
vs_top=(vs_base=base+1)+1;
(void) (*Lnk0)();
return;
}
}
It doesn't look like it inlines the sqr function.
Ray
Pierpaolo Bernardi
: Of the free Lisps, I think only CMUCL will actually inline your code.
I think _all_ of the free Common Lisps do obey inline declarations
(certainly Cmucl, Clisp and GCL do).
: Also, Tim mentions that Allegro does not support inline (maybe),
According to the manual, Allegro ignores user supplied inline
declaration, but decides on its own what to inline based on the
optimization settings.
Pierpaolo.