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 co...@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 _______________________________________________ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
