Kartik Agaram <a...@akkartik.com>:
> Rereading http://sourceforge.net/p/readable/wiki/Rationale for the
> case against precedence, it seems the major rationale against operator
> precedence assumes arbitrary infix operators. What if we instead
> restrict the set of infix tokens and give them hardcoded precedence?
> Has this idea come up before?
Absolutely. But the problem with restricting tokens is that anyone can create
a new operator that would be useful in infix position. If I create "equiv?", I
want to be able to use that, e.g., {x equiv? y}. Indeed, people want to be
able to do this:
{x ,op y}
where you do not even know, at compile time, what the operator *is*.
That said, it *would* be possible to support operator precedence for a set of
hardcoded operators, and then require explicit grouping for everything else.
I've even toyed with some possible systems. Things get complicated, though;
there are a lot of options in precedence systems, with a lot of room for
complaint no matter what you choose. And remarkably, after all that work, it's
not clear that it's worth it. And I think that there's a lot to be said for
the simplicity of no-precedence.
In the end, what matters is *adoption*. If people just won't use it without
some precedence support, then clearly it needs discussion. If people won't use
it *if* it has precedence support, well, that needs discussion too :-).
--- David A. Wheeler
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
