On Feb 5, 2008 12:04 PM, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> > A little off-topic, seeking to understand Lisp macros a little better:
> > do complex macros tend to not compose well because they're expanded
> > preorder rather than evaluation order (postorder)?
>
> 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.
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.
>
> Of course, there's always a trade-off; if you translate at read-time, then
> precedence
> rules get tricky - you have to make sure that the correct precedence rules are
> enabled when you read a particular expression. If there are snippets at
> various
> levels in the same read-expression, that's REALLY tricky.
> My solution is chop the problem off at the knees:
> no precedence, so no problems. In my experimentation this actually works
> surprisingly well; the loss of precedence is not really a big deal in a vast
> number
> of circumstances.
>
> I'm actually really happy with the latest version of sweet-expressions; I
> think
> it is extraordinarily general, and experiments seem to suggest it produces
> really
> nice results WITHOUT special-casing, etc., etc.
It sounds good, really. In such a case I would suggest that something
like {a + b * c} would be a reader error, requiring you to explicitly
say {a + {b * c}} or {{a + b} * c}, instead of passing that case to an
nfx macro.
Alternatively, you could support precedence for the sets +-*/ and &|
ONLY, and completely ban all other precedence. So {a + b * c} would
map to (+ a (* b c)) and {x & y | z} maps to (or (and x y) z), but {a
+ b | c + d} is an error. But I suppose this then becomes a slippery
slope; someone is going to question that line between allowed
precedence and disallowed precedence.
Sincerely,
AmkG
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/readable-discuss
