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 S. wrote:
Just. Use. Parentheses. Even in programming languages where the rules are clear. Explicit >> Implicit.David V.
Pavel S. wrote:
P.
To keep you on your toes…okay, I don’t actually know.
-Justin
Wayne V. wrote:
On 8/25/06, Pavel S. [email protected] 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. 
On 8/25/06, Pavel S. [email protected] 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."
Pavel S. 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.
On Tue, Aug 29, 2006 at 08:55:09AM +0900, Michael W. Ryder wrote:
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 8/30/06, Jürgen Strobel [email protected] wrote:
On Tue, Aug 29, 2006 at 08:55:09AM +0900, Michael W. Ryder wrote:
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.
–
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
On Thu, Aug 31, 2006 at 03:01:26AM +0900, Rick DeNatale wrote:
On 8/30/06, Jürgen Strobel [email protected] 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
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
Pavel S. 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?
David V. wrote:
Just. Use. Parentheses. Even in programming languages where the rules are clear. Explicit >> Implicit.Thanks for explanation, if there is any,
P.
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. 
On Aug 25, 2006, at 1:40 PM, David V. wrote:
Explicit >> Implicit.
STDOUT.puts “i disagree”
– Elliot T.
On Aug 25, 2006, at 12:38 PM, Alex Y. wrote:
tells 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
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 T.
On Aug 26, 2006, at 8:16 AM, David V. wrote:
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.
irb(main):025:0> true or true and false
=> false
irb(main):026:0> true || true && false
=> true
– Elliot T.
On Aug 26, 2006, at 16:16, David V. wrote:
(Yes, long time spent on that now, who would expect such a
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 8/26/06, Elliot T. [email protected] wrote:
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
Pavel S. wrote:
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
David V.
Matthew S. wrote:
conventions?
mathemathical rules to hold in programming languages, for the sake of
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.
M. Edward (Ed) Borasky wrote:
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 V.
David V. wrote:
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.)
Your memory is correct; Boolean + is OR, and Boolean * is AND. (You can
remember by observing that this makes the tables the same as arithmetic
in seven of the eight possible cases.) This is the reason that AND binds
more tightly than OR in nearly all languages.
(The designers of Ada, however, decided that not enough programmers are
familiar with Boolean Algebra, and defined the syntax in such a way that
AND and OR cannot be mixed in a single expression without explicit
parentheses.)
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs