[r6rs-discuss] Macro Timing and the Art of the Meta-Circular Interpreter

[John Cowan]

Alaric Snell-Pym scripsit:

> First, some definitions. I think we can take it as a given that a
> desirable feature of a macro system is that macro expansions should be
> decidable "before run time". It's overspecifying to call that "compile
> time", "link time", or "tea time"; 

I just call it "macro-expansion time".  But no, there is a small but
vocal minority that is absolutely opposed to this notion.

> That desire for being able to expand all the macros away before run
> time, revealing a semantically equivalent program without any macros
> in it (and from which all the macro definitions can therefore be
> stripped or ignored), is part of what makes fexprs bad.

Unfortunately, this argument is easily caricatured:

# That desire for being able to expand all the typecases away before
# run time, revealing a semantically equivalent program without any
# polymorphism in it, is part of what makes dynamic typing bad.

> It's also tied to another desirable property, that of being easy to
> reason about. Macros whose expansions can change at run time open up
> the potential for some terrible obfuscations of the meaning of a
> program.

I absolutely agree.

> On the other hand, one can go to the extreme in the other direction:
> you can produce a macro system that has no relationship whatsoever
> with the semantics of Scheme. A sort of "M4 for sexprs". Allowing just
> define-syntax at the top level and let-syntax elsewhere, with syntax-
> rules, produces this; you could write a macro-expansion function that
> takes a list of sexprs, some of which may be define-syntax, the rest
> of which may contain let-syntax or calls to defined macros, and return
> an expanded form - and use it for Scheme source code just as well as
> for SXML representations of HTML documents.

Indeed, that's what alexpander is.  Alexpander is only written in Scheme
for Al* Petrofsky's convenience: it could perfectly well be written in
Cobol (only with extra added pain) and would work in exactly the same way.

> For a start, you can macroexpand as you walk the code, whether that
> code-walk is for compilation or interpretation. The difference being
> that the compilation code-walk will not know the values of all
> symbols, while an interpretation codewalk will.

The essence of hygienic macro expansion (as opposed to pseudo-hygienic
macro expansion, or define-macro + gensyms) is that you have to walk
*all* the code.  It's not enough to just process forms with macro
keywords specially.

-- 
John Cowan  cowan at ccil.org  http://ccil.org/~cowan
If I have not seen as far as others, it is because giants were standing
on my shoulders.
        --Hal Abelson