and and or priority

P

Pavel Smerk

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.
 
J

Justin Collins

Pavel said:
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
 
A

Alex Young

Pavel said:
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?
 
E

Elliot Temple

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?

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
http://www.curi.us/blog/
 
A

Alex Young

Elliot said:
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? :)
 
D

David Vallner

Pavel said:
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
 
P

Pavel Smerk

David said:
<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. ;-)
 
D

David Vallner

Pavel said:
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
 
E

Elliot Temple

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 Temple
http://www.curi.us/blog/
 
M

Matthew Smillie

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.
 
W

Wayne Vucenic

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."
 
M

M. Edward (Ed) Borasky

Matthew said:
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. :)
 
D

David Vallner

M. Edward (Ed) Borasky said:
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
 
J

John W. Kennedy

David said:
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.)

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.)
 
P

Pavel Smerk

Wayne said:
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. :)
 
M

Michael W. Ryder

Pavel said:
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.
 
R

Rick DeNatale

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=
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,211
Messages
2,571,092
Members
47,693
Latest member
david4523

Latest Threads

Top