Alex Martelli wrote:
<snip>
>
> Preprocessors and macro processors may do different amounts of, say,
> "introspection" on their arguments. From the point of view of how to
> hack a preprocessor in front of the Python interpreter, that matters
> zilch. What DOES matter, of course, is that the language/metalanguage
> confusion becomes a bit harder (but far from impossible) to architect into
> a preprocessor that's supposed to receive text as input and hand text back
> to the following phase[s], rather than working on (e.g.) AST kinds that
> are in common with other phases (and s-exprs are such) -- but plugging a
> parser in front of a custom preprocessor and a code formatter as its
> tail is hardly impossible, if that's how you want your macros to work.
>
<snip>
Based on your comments, I still think you do not understand
macros. It is probably my fault for not explaining them well
enough.
An *external* preprocessor, no matter what sophisticated
parsing, etc. it does, can never do the same things macros
can do (because it's *external*), it can not access
the contents of the running program *image* (values,
functions, classes defined).
Like I said, I think you just need to take a little break,
play with macros if you feel like it, do the exercises
in Lisp books. After that, you will at least know
what you are talking about (no offense).
As to the rudeness of fans of macros: we are not rude,
we are curt. And if we are curt with you, it's because time
is a factor.
420
P.S. "defense" is *a* correct spelling. Suck on this :-)
P.P.S. ARC is a Lisp, and it has macros, how can it be a
threat to Lisp?