guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Please explain different macros


From: Keith Wright
Subject: Re: Please explain different macros
Date: Wed, 25 Apr 2001 17:16:11 -0400

> From: Rob Browning <address@hidden>
> 
> Michael Livshin <address@hidden> writes:
> 
> > it's tricky.
> > 
> > the R5RS macros are implemented through the portable syntax-case
> > implementation.  syntax-case pre-processes the Scheme source
> > before it gets to the eval -- so it's kind of slow, and it
> > processes all the code, even though your particular program may
> > not excersize all the code it loads.
> 
> But just to be clear, this happens at load time, not execution time,
> right?

Just to be unclear---what do you mean by load time?
I the case of dynamically loading a library, load time
_is_ execution time.  I think R5RS leaves you with no way
to tell exactly when macro expansion happens.  The
evaluation of a function can't do anything that would
affect the way a macro is expanded.  The obvious way to
implement macros is to expand them all at once as you
convert the program from Ascii text to lists of symbols
or byte codes or machine code---whatever the internal
representation of a program.

But in an interactive programming system you may have
evaluated many functions before you decide to load
another big chunk of code.  If loading is too slow, I
see nothing to prevent the implementation from loading
unexpanded code and expanding the macros just before
you evaluate a particular sub-expression for the first
time.

In any case, the whole process should be linear in the
length of the program text[*].  There is no R5RS program
you can write that asks for a macro to be expanded more
than once or depending upon input to the program.

Of course it's always possible to add extentions that
break this property.  I don't understand the various
other macro types of guile well enough to comment on
whether they can be used to break inside R5RS macros.
Mixing the macro systems seems like asking for trouble.

[*] At least for practical purposes.
After writting that I began to doubt that it is
literally true unless restricted to "honest" macros.
Here "honest" is used in a the technical sense of
complexity theory, which if you don't know you don't
care.  There may be an example which takes a short
input and expands into a very long program which is
then reduced to a short output.  I don't know how to
write such a thing, I doubt it could be done except
by a clever troublemaker, and I wish to wave my hand
at him and make him go away.  If you do that it may
make macro expansion slow.  So what?

-- 
     -- Keith Wright  <address@hidden>

Programmer in Chief, Free Computer Shop <http://www.free-comp-shop.com>
         ---  Food, Shelter, Source code.  ---



reply via email to

[Prev in Thread] Current Thread [Next in Thread]