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 :-(.
> > 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.
Well, as I note in the docs, you could define "nfx" as an error. That has the
same effect.
Alan Manuel Gloria:
> 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.
Right!! That is EXACTLY the problem I've had, and I've debated this to myself
several times. If you allow ANY, then it's not clear where to end it, and you
have
to train users on these exceptions.
The weirdest case (from the viewpoint of new users) is that:
{a + b - c}
does not work "as expected", because "+" and "-" are different operators.
If you want it to create a simple expression, you need:
{{a + b} - c}
or
{a + b + -(c)}
For the moment, I've decided that simplicity is most important.
If there's a particular set of operator precedence that ALL agree on, then
they could be added later as a special case. But once added, these special
cases are hard to remove.
There's a pretty good case to be made for + and - being left-to-right
associative,
and for * and / being left-to-right associative with higher precedence than
binary + and -. I know of NO significantly-used notation that violates that.
After that, it seems to be "whatever".
--- David A. Wheeler
-------------------------------------------------------------------------
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
