Re: Macro uexpansion

[Craig Brozefsky]

Mikael Djurfeldt <address@hidden> writes:

> Both evaluation time and environment of macros are well defined in the
> syntax-case macro system independently of this discussion:
> 
> * evaluation time for macros is any time
> 
> * environment for the macro is any top-level environment supplying
>   at least the R5RS bindings and with a guarantee that all top-level
>   macros is expanded in the same environmnet

I had forgotten that aspect of the syntax-case macro system, having
been using the "lisp" macros whenever I use scheme for the last couple
years 8)

> Concerning your debug example, I think it could be seen as a strength
> to be able to switch off the debugging code in all places referring to
> one particular variable.  It also seems simpler to think about than
> remembering *when* various parts of the system were loaded.

If you wanted that behavior than you would have the macro expand into
code that checks the current *debug* binding, explicitly telling the
systme to make that decision at run-time instead of at load-time.

> So, with these three rules, we're safe:
> 
> 1. No guarantee about evaluation time
> 
> 2. No guarantee about environment (except it's the same for all
>    top-level invocations in the same module)
> 
> 3. No guarantee about the number of times a use is expanded
> 
> This kind of "no guarantees" is actually a strength of a language
> since it gives flexibility to the implementor and to future
> development.

Given those design decisions, my complaints about macro unexpansion
causing inconsistency in the distinction between (re)definition and
expansion don't have much to stand on, since that consistency was
"undefined" by the language in the first place.

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