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.
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.
To keep you on your toes...okay, I don't actually know.
-Justin
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?
Good question.
irb(main):001:0> true and false or true and false
=> false
tells me that and binds tighter than or, unless something unobvious is going on, which might well be...
Have you got a counterexample handy?
--
Alex
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>
David Vallner
Matz answered this question on the mailing list on 24 Sep 2002:
"Because english words "and" and "or" does not have precedence order.
matz."
On 8/25/06, Pavel Smerk <smerk@fi.muni.cz> wrote:
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?
-----------
Wayne Vucenic
No Bugs Software
Ruby, C#, Prolog Agile Contract Programming in Silicon Valley
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.
Smalltalk evaluates and and or operators the same way. Most evaluation is done from left to right with only a few different priorities.
irb(main):008:0> true or true and false
=> false
If "and" had higher priority, that'd evaluate as:
true or true and false
true or false
true
I think it's going left to right:
true or true and false
true and false
false
Pickaxe page 339 says they have the same priority and calls them "logical composition" operators.
As to the OP's question: I don't know why.
-- Elliot Temple
On Aug 25, 2006, at 12:38 PM, Alex Young 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?Good question.
irb(main):001:0> true and false or true and false
=> falsetells me that and binds tighter than or, unless something unobvious is going on, which might well be...
Have you got a counterexample handy?
STDOUT.puts "i disagree"
-- Elliot Temple
On Aug 25, 2006, at 1:40 PM, David Vallner wrote:
Explicit >> Implicit.
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. 
Wayne Vucenic wrote:
On 8/25/06, Pavel Smerk <smerk@fi.muni.cz> wrote:
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?Matz answered this question on the mailing list on 24 Sep 2002:
"Because english words "and" and "or" does not have precedence order.
matz."
Hmmm. Roma locuta, causa finita, and, I'm afraid, my quiet disagreement with this inconsistency is all, what I can do with that. 
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.Smalltalk evaluates and and or operators the same way. Most evaluation
is done from left to right with only a few different priorities.
Yes, and this is consistant behaviour for Smalltalk, as Smalltalk uses
left to right evaluation even for +, * arithmetic.
I wouldn't say it is wrong the way ruby does it, but not exactly
intuitive either. Choosing to follow english language rather than
widespread convention *and* similiar constructs in ruby itself (&&,
, +, *, ...) may seem a bit ... anti POLS.
I feel this is a true case of POLS violation, not one of those "I
don't know shit, and I was surprised" examples. I do know about
operator precedence in ruby in general, and was surprised by this
special case. Never ran into it myself though, probably because of
luck or spurious parentheses.
It's not a major deal. It certainly can't be changed in 1.8 without
breaking code. Who feels this is worth changing in 1.9?
-Jürgen
On Tue, Aug 29, 2006 at 08:55:09AM +0900, Michael W. Ryder wrote:
--
The box said it requires Windows 95 or better so I installed Linux
Elliot Temple 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?Good question.
irb(main):001:0> true and false or true and false
=> falsetells me that and binds tighter than or, unless something unobvious is going on, which might well be...
Have you got a counterexample handy?
irb(main):008:0> true or true and false
=> false
Good counter-example Now I understand. It seems to be evaluated in terms of the first encountered. Unless... that's wrong too?
On Aug 25, 2006, at 12:38 PM, Alex Young wrote:
--
Alex
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
> Smalltalk evaluates and and or operators the same way. Most evaluation
> is done from left to right with only a few different priorities.
Yes, and this is consistant behaviour for Smalltalk, as Smalltalk uses
left to right evaluation even for +, * arithmetic.
Smalltalk only prioritizes between
unary selectors which bind the tightest
binary selectors which are next (so a negated + b is (a negated) + b
keyword selectors which are last
object jump: x + y * z towards: fred location
is interpreted as
object jump: ((x + y) * z) towards: (fred location)
I wouldn't say it is wrong the way ruby does it, but not exactly
intuitive either. Choosing to follow english language rather than
widespread convention *and* similiar constructs in ruby itself (&&,
>>, +, *, ...) may seem a bit ... anti POLS.
A perl programmer would be very surprised if AND, OR, && and || worked
any other way. Probably the most common perl idiom here is:
"some long complicated expression" or die
I feel this is a true case of POLS violation, not one of those "I
don't know shit, and I was surprised" examples. I do know about
operator precedence in ruby in general, and was surprised by this
special case. Never ran into it myself though, probably because of
luck or spurious parentheses.
It's often pointed out that it's impossible to minimize EVERYONE's surprise.
It's not a major deal. It certainly can't be changed in 1.8 without
breaking code. Who feels this is worth changing in 1.9?
Not I.
On 8/30/06, Jürgen Strobel <strobel@secure.at> wrote:
On Tue, Aug 29, 2006 at 08:55:09AM +0900, Michael W. Ryder wrote:
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
&& binds before ||
Presumably there is a special reason for and/or to be the way they are. We should probably find out what it is before suggesting it be changed.
irb(main):025:0> true or true and false
=> false
irb(main):026:0> true || true && false
=> true
-- Elliot Temple
On Aug 26, 2006, at 8:16 AM, David Vallner wrote:
I agree that the and should bind more tightly than or now that that's been brought up.
Is that actually a mathematical rule, though? I don't remember as such from any math or logic that I know, and poking around through my old textbooks made no mention of binding or precedence of logical operations; the closest thing being a statement that parentheses are required to avoid ambiguity when mixing and and or in one statement, at least slightly implying that there is no 'order of operations'.
If anyone has a reference either way on this, I'd be curious to see it.
matthew smillie.
On Aug 26, 2006, at 16:16, David Vallner wrote:
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.
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.
That's not a complete example, as no precedence rules come into play
here. and and or are pretty low-precedence operators in perl and ruby
alike, which makes constructs like the above possible without
parenthesises. But what I am driving at is this:
irb(main):035:0> 1 + 2 * 6
=> 13
irb(main):036:0> 1 | 2 & 6
=> 3
irb(main):037:0> 1 | (2 & 6)
=> 3
irb(main):038:0> (1 | 2) & 6
=> 2
Clearly, & binds stronger than |, same as * binds stronger than +.
(In a boolean algebra those operations are the same
respectively).
irb(main):073:0> def pr(x) p x; x; end
=> nil
irb(main):076:0> (pr 1) || (pr 2) && (pr 3)
1
=> 1
irb(main):077:0> (pr 1) or (pr 2) and (pr 3)
1
3
=> 3
In the first case, && binds stronger than ||, but is short circuited
away. In the second case "and" does not bind stronger than "or", which
suprised me, given prior knowledge. Is it really only me?
-Jürgen
On Thu, Aug 31, 2006 at 03:01:26AM +0900, Rick DeNatale wrote:
On 8/30/06, Jürgen Strobel <strobel@secure.at> wrote:
>On Tue, Aug 29, 2006 at 08:55:09AM +0900, Michael W. Ryder wrote:
>I wouldn't say it is wrong the way ruby does it, but not exactly
>intuitive either. Choosing to follow english language rather than
>widespread convention *and* similiar constructs in ruby itself (&&,
>>>, +, *, ...) may seem a bit ... anti POLS.A perl programmer would be very surprised if AND, OR, && and || worked
any other way. Probably the most common perl idiom here is:"some long complicated expression" or die
--
The box said it requires Windows 95 or better so I installed Linux
> I agree that the and should bind more tightly than or now that
> that's been brought up.&& binds before ||
Presumably there is a special reason for and/or to be the way they
are. We should probably find out what it is before suggesting it be
changed.
The general idea is that you can use and and or in similiar places as if and
unless modifiers (ala "or die" in perl, at least as far as I understand it)
e.g. x = string.index("h") or raise "No h in string!"
Also with left to right equal precendence you can use them as a ternay
operator:
x = condition and value or other_value
irb(main):025:0> true or true and false
On 8/26/06, Elliot Temple <curi@curi.us> wrote:
On Aug 26, 2006, at 8:16 AM, David Vallner wrote:
=> false
irb(main):026:0> true || true && false
=> true-- Elliot Temple
Curiosity Blog – Elliot Temple
Matthew Smillie wrote:
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.
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.Is that actually a mathematical rule, though? I don't remember as such
from any math or logic that I know, and poking around through my old
textbooks made no mention of binding or precedence of logical
operations; the closest thing being a statement that parentheses are
required to avoid ambiguity when mixing and and or in one statement, at
least slightly implying that there is no 'order of operations'.If anyone has a reference either way on this, I'd be curious to see it.
matthew smillie.
My rather dim recollection is that computer jocks forced "and" to bind
tighter than "or" and "not" to bind tighter than "and" just so it *was*
defined. Only in programming (and logic design) do you usually find
Boolean expressions complicated enough for operator precedence to matter.
Meanwhile, the logicians pretty much abandoned parentheses for Polish
(prefix) notation. And of course, the computer jocks, not to be outdone,
invented *reverse* Polish notation.
On Aug 26, 2006, at 16:16, David Vallner wrote:
M. Edward (Ed) Borasky wrote:
Matthew Smillie wrote:
Is that actually a mathematical rule, though? I don't remember as such
from any math or logic that I know, and poking around through my old
textbooks made no mention of binding or precedence of logical
operations; the closest thing being a statement that parentheses are
required to avoid ambiguity when mixing and and or in one statement, at
least slightly implying that there is no 'order of operations'.If anyone has a reference either way on this, I'd be curious to see it.
matthew smillie.
My rather dim recollection is that computer jocks forced "and" to bind
tighter than "or" and "not" to bind tighter than "and" just so it *was*
defined. Only in programming (and logic design) do you usually find
Boolean expressions complicated enough for operator precedence to matter.
Hmm. If I recall my freshman discrete maths, logical conjunction (and) was the multiplicative operation in boolean algebra, logical disjunction (or) was the additive operation. Or at least were denoted by the same symbols and the analogy made it easier to remember the meaning of those symbols than ∧ and ∨. And in arithmetical maths expressions, multiplication binds before addition. So I might have jumped to the conclusion that in boolean expressions, and would bind before or. (Or made a really lucky guess as to the correct convention.)
Either way, operator precedence is a convention, not a rule - just a very widespread convention. And speaking of logic design, that I remember to really have beastly logical expressions in it. And wonder of wonders, I also remember that terms using one operator were always parenthesized.
David Vallner