Re: Macro uexpansion

[Mikael Djurfeldt]

Jim Blandy <address@hidden> writes:

> I have to say:
> 
> a) macros which are powerful enough to run arbitrary code to determine
>    the expansion, and
> 
> b) an evaluation framework which doesn't tell you whether, when, or how often
>    an expansion will happen
> 
> seem fundamentally irreconcileable to me.

Why?  You extremely seldom need to know when a macro transformer
executes.  If you read through the chapter on syntactic abstraction in
Dybvig's book, I'm sure you won't find a single example which is
dependent upon such knowledge.

> If I cannot control when expansion will happen, then the flexibility
> a) offers is useless, because I can't reliably use it.

Not true.  The fact is that you normally don't need to rely on it.
Also, cases where you indeed do depend on it are usually suspect
since they are hard to reconcile with separate compilation.

There in fact *is* a special form in the syntax-case system which
gives you some control over what is evaluated when: the "eval-when"
construct.

> If I can write macros that run arbitrary code at expansion time, then
> it must be apparent when that expansion will happen.

No.  And this is not something new which I bring into the discussion.
This was the case with the low-level macro system in R4RS and this is
the case with syntax-case.

> This is exactly the kind of unfortunate coincidence of 'flexibilities'
> that Craig is warning us about; he's telling us that the CL community
> found this to be a serious problem.

I'd like to see some examples of these serious problems.  I have hard
to believe that making restrictions to what you are allowed to do
causes serious problems if these restrictions don't prevent you from
everyday use of the system.

Also, note that the only of the three restrictions which *I* have
introduced is the onw about how many times the expansion occurs.

The rest of the restrictions follows naturally from the separation of
compilation time and run time.

> Mikael, it sounds like this doesn't bother you, which I consider a
> serious gap between us.  If we don't share some common understanding
> on something so fundamental, I'm not sure we're ready to discuss
> details yet.

Which details are you referring to?

These things bothered me a lot the first time I read the R4RS
appendix.  At that time I was playing around with macro systems myself
and implemented one myself.  I finally got convinced that the
restrictions (except the third one) are sound.

Mikael