David A. Wheeler wrote:
> I said:
>>> Actually, complex macros work just fine, as long as you stick to the
>>> Lisp convention that "operator is always named first in a list". As long
>>> as you do that,
>>> complex macros that reach deeply into their parameters will still work.
>>> But this is
>>> why infix operators have trouble - the operator is NOT first in an infix
>>> expression.
>>> By making this translation at read-time, complex macros work again.
>
> Alan Manuel Gloria:
>> Well, the operator in this case is the infix-macro name (say nfx).
>> Although this does prevent the complex macros from digging inside the
>> (nfx ...) form easily.
>
> It's not just "easily"; they better not dig in at ALL. Because they'd have
> to understand
> details about "nfx" to work, and fail once "nfx" changes :-(.
This is what I was on about before. It seems to me that things would be
safer, if upon
(foomacro (nfx 1 + 1) ...)
nfx was expanded first, and then foomacro. Then foomacro wouldn't have
to care what nfx does, because foomacro always receives expanded
s-exprs. It fits my programmer intuition better as well: since I ALWAYS
expect postorder evaluation, why should I expect preorder macro expansion?
Not that you're in a position to change anything. :)
Neil
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
