On Wed, Sep 12, 2012 at 10:40 AM, David A. Wheeler <dwhee...@dwheeler.com> wrote: > 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.
Here's an example of what David is describing: http://sourceforge.net/p/readable/wiki/Precedence/ Sincerely, AmkG ------------------------------------------------------------------------------ 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
