This page is part of the web mail archives of SRFI 53 from before July 7th, 2015. The new archives for SRFI 53 contain all messages, not just those from before July 7th, 2015.
I think that there's a line of expressiveness that can't really be crossed with a compile-time macro system. One of the "cool things" about Lisps, in general, is their ability to manipulate their own code as data. To create a macro system, as both CL and Scheme have at this point, that works purely at compile-time and/or link-time does walk away from the expressive power that first- class syntax-transforming macros, which can be stored in variables and structures and passed as arguments or returned from functions, etc, provided in early lisps. I am of the opinion that the huge stumbling-block that scheme macrology has presented for would-be standardizers of package and module systems is a sign from God that Scheme is using one of many possible Wrong macrologies. Analyzing the ways in which macro semantics break down in package and module systems has led me to question even the stated semantics for definitions in a file given in R5RS, which states that definitions will be evaluated from the beginning of a file to its end. This does not generalize well to programs with macros in several files, because order of compilation becomes significant and then separate compilation becomes difficult or impossible. So, I'm of the opinion that the "Right thing" is some kind of macro system that allows everything which can possibly be allowed and which can be succinctly expressed and unambiguously defined, regardless of whether it's hygienic or has huge performance hits. A few optional declarations to tell the compiler when it can make particular assumptions as to compilation phase, or whether the macro is inline-able or constant over the life of the program are certainly called for when high-performance programs are needed; but these considerations should not, except in error situations or where the programmer inappropriately relies on unspecified behavior, affect the semantics of the macro system. These are just my opinion, which are mine and belong to me; other folks can disagree without me being upset about it. My point here is that the problem area in which this SRFI operates (macrology) has vasty deeps where no mind has yet gone. I have not yet seen a macrology proposal more powerful than syntax-rules that is compatible with both the language presented in R5RS and the possibility of separate compilation of modules. Syntax-rules clearly isn't powerful enough, because we are still thinking about it. Short of a system in which macro transformers are first-class values like any other procedure (and yes, I know how horrible that is for performance) I don't think a truly general and semantically simple macrology for a lispy language can exist. Bear