From: David Vallner <david@...>
Date: 2006-08-27T00:16:05+09:00
Subject: Re: and and or priority

Pavel Smerk wrote:
> David Vallner wrote:
>> Pavel Smerk wrote:
>>
>>> OMG!
>>>
>>> Why the and and or operators have the same priority? Unlike && and || 
>>> and also unlike the most of, or maybe all, other languages and 
>>> conventions?
>>>
>>> (Yes, long time spent on that now, who would expect such a curiosity...)
>>>
>>> Thanks for explanation, if there is any,
>>>
>>> P.
>>>
>>
>> <rant>
>> Just. Use. Parentheses. Even in programming languages where the rules 
>> are clear. Explicit >> Implicit.
>> </rant>
> 
> More parentheses, less readability. E.g. the natural language is quite 
> well understandable without the parentheses --- and (((I'm) sure), 
> (((it's) (better understandable)) (than (it (((would be) understandable) 
> (with them)))))). May be its operator precedence is better designed than 
> the ruby's one? (Although it can be hardly believable that something 
> could be even better than ruby. ;-)
> 

And for Christmas, I want a pony or a doggy and rollerskates and a bike 
or a computer and an action figure and a toy car or a goldfish or new 
shoes and a TV.

So...

Perfectly understandable? Only if people naturally follow boolean 
algebra rules when talking. (Riiight.) Of course, the above sentence is 
particularly convoluted (making it no more a contrived example than 
yours I'd say though), that's why it's pretty much impossible to 
determine what it's supposed to say. Which is my point: if you want 
programming language code as readable as natural language, just using 
words instead of symbols doesn't cut it - you should phrase your 
expressions clearly nonetheless. Like, oh, without long tangles of ands 
and ors.

For what it's worth though, since most programmers DO expect 
mathemathical rules to hold in programming languages, for the sake of 
consistency, I agree that the and should bind more tightly than or now 
that that's been brought up. I just don't really consider it critical 
since I believe you should never mix those in a single expression at all 
- boolean expressions are for me much easier to visually parse as "one 
must be true" or "all must be true" when you don't have nested anonymous 
complex terms involved. Those are a good candidate for extraction into a 
local variable or a separate predicate method.

David Vallner