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