Cobra Forums

I'm putting this here since it's worthy of discussion, and the ticket isn't a place for discussion.

This was intentional rather than accidental. I don't see that adding another operator precedence level is advantageous, or that you wouldn't want the parens for added clarity. I'll close this ticket unless I'm convinced otherwise.

And being higher than Or and Times/Divide being higher than Plus/Minus is not arbitrary, it's the standand rule for mathematics and for logic, and it's how and C, C++, C#, Python, Perl, Php, Java, Visual Basic, and Eiffel work.

http://en.wikipedia.org/wiki/Logical_connective#Order_of_precedence

Operator Precedence
not 1
and 2
or 3

'And' has higher precedence than 'or' for the same reason that * has higher precedence than +.

http://mathforum.org/library/drmath/view/52582.html

The standard order of operations, or precedence, is expressed in the following chart.
exponents and roots
multiplication and division
addition and subtraction

1. The basic rule (that multiplication has precedence over addition) appears to have arisen naturally and without much disagreement as algebraic notation was being developed in the 1600s and the need for such conventions arose.

How is it advantagous is that it doesn't have the disadvantages of turfing conventions from hundreds of years of mathematics and logic and that most programmers know and expect.

In a book on Cobra I'd expect it to appear as a note in a box with a warning icon saying look out!

What do other people think? Have you noticed this? Does it change your code?

Actually I hadnt noticed till nev pointed it out.
OTTOH (since C) I tend to parenthesize to explicitly indicate desired precedence and simplify expressions anyway.
This has worked fine for me across numerous systems and languages and as well as making it
explicit whats desired/happening I dont have to care about whatever hidden gotchas may be buried in the precedence rules.

Happily Cobra works out a + b * c correctly without making me write a + (b * c), and lets me add the brackets if I need them.

As language designers (of a f'ing cool language) I think the question to answer is "what is technically correct?", rather than "have I noticed it? do I have a workaround for it?".

BTW, hopscc, can I ask your name?

Sure.

....
(Mike Hopkirk (hops))

I like the order of operations of And/Or being at the same level. That is decidedly not like the other languages I work with (C# being my primary/work language). However, this does go against well established conventions... so I can see Nev's case for changing it.

So the question (IMO) is: Does Cobra wish to conform on this area so as to be consistent, or does it wish to make a breaking change? I think you can look at this being analogous to are numbers using float/double or decimal as the underlying type. Perhaps you want a switch at the compiler level that lets a person tailor it based on their needs and desires, just like with numbers.

Hi torial,

torial wrote:I like the order of operations of And/Or being at the same level.

What's your reason for liking them at the same level? And would you then put "* / % //" at the same level as "+ -"?

a*b/c, (a*b)/c, a*(b/c) all give the same result, and that is why * and / are at the same level. (Not withstanding integers truncating.) But a+b*c, a+(b*c), (a+b)*c don't, and so * and + are not at the same level.

BTW, I am writing regression tests for operator precedence for the test suit. (Which so far all pass - minus this and/or issue.)

Hi Nev,

Basically, I find And/Or to be equivalent at an intuitive level... perhaps when I took a few semesters of electrical engineering.. And/Or just get wired up however you want (but I was a lousy EE in lab, so I could be wrong!) . I can't give you any basis other than that, and was unaware that numerous conventions had And/Or at different precedence levels. The convention strikes me as arbitrary, like selecting <, <=, = to have a higher precedence than >,>= would seem.

In terms of */ vs +-, those are separate types of operations. If I had to justify why exponentiation is higher precedence than multiplication/division, and multiplication/division is higher than addition/subtraction, it would be that the higher precedence in these cases can be composed/represented by multiple lower precedence operations. i.e. multiplication can be represented by numerous additions, exponents can be represented by numerous multiplications.

Sean

Well, I can't find anything that says 'why' boolean logic has those rules, but every reference for logic and mathematics that I've found says the same.

One slight variant I found are Ruby's 'and/or' which have the same precedence, but they are for control structures, not boolean logic. It has &&, || for boolean logic and && has higher precedence than ||. I'd not come across its and/or for control flow before. I've not programmed in Ruby. It might be in Perl too, dunno.

So I just put it here for interest sake... http://avdi.org/devblog/2010/08/02/using-and-and-or-in-ruby/

Everything I've found on boolean logic says the same thing...

Order is parenthesis then logical NOT then logical AND then logical OR. The logical AND and OR operators are left associative. If two operators with the same precedence are adjacent, you must evaluate them from left to right. The logical NOT operation is right associative.

I guess only a math nerd could give the definitive answer to Why?

BTW, IMPLIES should be lower than OR. Cobra has implies at the same level as and and or too?

I did manage to find *one* scenario of equivalence (aside from Cobra) in a programming language, and it was for the Second Life scripting language (LSL): http://wiki.secondlife.com/wiki/LSL_Operators

But in my mind, such examples don't matter much (even though I favor the equivalence of And/Or). I think it comes down to philosophical/subjective questions: a) Is this a change for the better? If not, don't do it. (this is entirely subjective in this case, unfortunately, probably akin to people requesting pipes for lambdas IIRC ), b) Is the value provided worth deviating from the existing convention?

If you take the whole ... how are numbers handled by default, and find that Chuck observed that decimal had numerous over using float/double for most situations, so answered yes to a), and then yes to b), but provided a fall back for those who needed it. So there is precedence for deviating from the convention of other languages.

Hmmm.. I'd say: unless the majority of Cobra users find And/Or being equivalent to be more intuitive (which I am in that camp), I don't think it has any other merits going its way to overcome the vast amount of convention.

Anyways, regarding the convention for boolean, I just checked Algol, just to see something Pre-C, and it has And as higher than Or.....