Re: Macro uexpansion

[Craig Brozefsky]

Mikael Djurfeldt <address@hidden> writes:

I may have developed the reputation of the Common Lisp pundit during
the last few threads about object systems.  However, my commentary is
not meant to be a reactionary "make it like Common Lisp" screed.
Rather, it is intended to point out some of the reasons behind the
decisions Common Lisp's designers made, and what implications that
could have on guile, which as a Scheme is addressing many of the same
issues the Common Lisp designers faced.  Wether guile goes in the same
direction as Common Lisp or not is not the important thing here, I
just want guile to have a cohesion between all it's parts that creates
a useful and viable environment.

> Quite angry I thought: "This is a BAD development environment."
> It kind of only went half of the way: Yes, it was interactive, but as
> soon as you've worked on a few definitions, your system is in a
> totally inconsistent state.

I have had this same situation happen many times.  A particularly
annoying pattern is when your working on a "with-blah" macro that's
used in alot of places and it's taking you some time to get the kinks
out.

> Macro unexpansion seems to amend this a bit.  For example, the
> behaviour of a function FOO using a macro BAR won't anylonger be a
> function of when or if the definition of FOO has been evaluated, but
> solely depend on the current definition of BAR.

Macros are programs, programs which produce another program.  A
program's result depends upon the environment it is evaluated in.  It
seems that macro unexpansion changes the environment a macro program
is evaluated in, and therefor changes the results.  It does this by
collapsing the (re)definition and evaluation time of the macro into
the same event, and it doesn't do that consistently either.

I worry that macro unexpansion might introduce more issues for
developers than it removes.  The seperation of (re)definition and
evaluation time is a useful feature of macros.  A simple example is a
macro that expands into different things depending on wether *debug*
is bound to T or NIL.  A redefinition, and I'm not sure if unexpansion
only "unexpands" when the macro has actually changed (good luck
defining what that means) or "unexpands" whenever its definition is
re-evaluated, could do things like turn off debugging in all the
previously loaded code which used that macro, despite the fact that
the programmer made sure *debug* was bound to T when loading them and
expects them to have debugging code inserted.

Remember, macros aren't just function's that don't evaluate their
arguments, they are programs that produce programs.  It might be
better to not make their evaluation time and environment nearly
arbitrary.

-- 
Craig Brozefsky                   <address@hidden>
LispWeb -- Mailing list for Lisp Based Web Development
Homepage:              http://www.red-bean.com/lispweb