And has same precedence as Or

[Charles]

Sure.

....
(Mike Hopkirk (hops))

I'm curious too: What's the "cc" in "hopscc" for?

[Charles]

One thing I like about putting "and" and "or" at the same level is that it requires the developer to clarify complex boolean expressions with parenthesis. I say "clarify" because whereas "x + y*z" is immediately clear to me, "foo and bar or baz and buzz" is not. And that's despite the fact that during my lifetime I've done most of my coding in languages that put "and" greater than "or".

Of course, that begs the question "why is the complex boolean expression not immediately clear?" but I can only speculate. Maybe it's because the terms in a boolean condition are often more complex terms themselves which spread out the whole expression. In other words "foo" and such are often "x < y" or "obj.bizz(a, b)" rather than just an identifier.

Also, until Nev's post, I don't think anyone has been impacted by this contrarian approach. It doesn't appear to be harmful in practice.

This is where I currently stand on this topic.

[nevdelap]

"Why is the complex boolean expression not immediately clear?" - A. Because if it was immediately clear it wouldn't be called 'complex'. Saying a simple expression should be bracketed for clarity because it might actually be a complex expression is contradictory.

"foo and bar or baz and buzz" is immediately obvious to me, given that is it not complex, except that Cobra is currently making it "(((foo and bar) or baz) and buzz)" instead of "(foo and bar) or (baz and buzz)" that anyone who has bothered to understand operator precedence in almost any other language or in their school or university math courses should expect it to be.

If '*' higher than '+' is basic high school mathematics (it was in my high school) then Cobra programmers should be able to cope with 'and' higher than 'or' and not be forced to depart from the rest of the mathematical world - otherwise it leads to the person who knows boolean precedence being tripped up and thinking Cobra's implementation is lame instead of the person who doesn't know it being tripped up and learning something.

Having reported 28 of the last 41 bugs (not withstanding a couple of them not being considered bugs like this one) I seem to be noticing many things that no-one else is. I wonder how many people 'not being impacted' actually is.

I'll be looking forward to a technical reason to make such a fundamental 'contrary' design decision. So far they've all been subjective.

[hopscc]

re 'cc'
Cobra Compiler.
FWIW Where I have to register on a web site I try and tag the name I use to be reminded what it refers to if the name surfaces elsewhere
(e.g out of band mail messages or spam). It also helps uniqify the name if someone has already used it ( hops isnt that uncommon evidently)

I seem to be noticing many things that no-one else is

Thats a positive way of looking at it .. OTOH there always the possibility that you're noticing things that noone else cares about

So far they've all been subjective,

Its always subjective - sometimes they are just dressed up better to appear purely objective and logical....

[nevdelap]

Do you want me to report only the bugs I 'care about', or the bugs I find? Probably 23 or 24 of them are uncontroversial.

[hopscc]

Report what you like,
(Get agreement that they're bugs)

Fix what you report.

[nevdelap]

Ok. But I've added a few words to the wiki. You might want to check that you are happy with them. I think it is important because boolean logic is so fundamental to both contracts and tests expressed as assertions. So I'll shut up now.

http://cobra-language.com/trac/cobra/wiki/Contracts
http://cobra-language.com/trac/cobra/wiki/C

This isn't wiki so I can't add to it, but it could use something similar under that Contracts, Testing, and Assertions sections.
http://cobra-language.com/docs/python/
http://cobra-language.com/docs/quality/

[Charles]

"Why is the complex boolean expression not immediately clear?" - A. Because if it was immediately clear it wouldn't be called 'complex'. Saying a simple expression should be bracketed for clarity because it might actually be a complex expression is contradictory.

I now regret saying "complex". I should have said "compound". The arithmetic example I gave is also compound, but immediately clear to me and anyone I know.

"foo and bar or baz and buzz" is immediately obvious to me, given that is it not complex, except that Cobra is currently making it "(((foo and bar) or baz) and buzz)" instead of "(foo and bar) or (baz and buzz)" that anyone who has bothered to understand operator precedence in almost any other language or in their school or university math courses should expect it to be.

And yet many people, including myself, will often put the extra parens on compound expressions and find them less clear when they don't have them. I think the extra parens are worthwhile.

If '*' higher than '+' is basic high school mathematics (it was in my high school) then Cobra programmers should be able to cope with 'and' higher than 'or' and not be forced to depart from the rest of the mathematical world - otherwise it leads to the person who knows boolean precedence being tripped up and thinking Cobra's implementation is lame instead of the person who doesn't know it being tripped up and learning something.

That sounds reasonable, but in practice it has rarely been a problem. August 2010 is the first time anyone has brought it up. That has to be attributable to something, because I think we can all agree that if * and / were at the same level as + and - that would have been brought up in Jan/Feb 2008 when Cobra was widely announced.

Having reported 28 of the last 41 bugs (not withstanding a couple of them not being considered bugs like this one) I seem to be noticing many things that no-one else is. I wonder how many people 'not being impacted' actually is.

I've had plenty of feedback on Cobra since it was widely announced. Bitwise operators. Syntactic conveniences. Compiler options. Etc.

I'll be looking forward to a technical reason to make such a fundamental 'contrary' design decision. So far they've all been subjective.

But there are a lot of subjective decisions behind any language design. For example: Why does Cobra have a fairly complex expression grammar instead of being stack-based or list-based, which are arguably more elegant? And why does Cobra dictate reference vs. value at the declaration level (class vs. struct) rather than at the argument/var level (like C++'s "Foo" vs. "Foo &") which is more flexible?

What's more, subjective decisions are based on experience and this makes them difficult to discuss and debate the merits of. Nonetheless, you cannot create anything of import without making subjective decisions.

[Charles]

Ok. But I've added a few words to the wiki. You might want to check that you are happy with them. I think it is important because boolean logic is so fundamental to both contracts and tests expressed as assertions. So I'll shut up now.

http://cobra-language.com/trac/cobra/wiki/Contracts
http://cobra-language.com/trac/cobra/wiki/C

First of all, thank you for contributing to the wiki. I did tighten up the wording, but preserved the message you added.

This isn't wiki so I can't add to it, but it could use something similar under that Contracts, Testing, and Assertions sections.
http://cobra-language.com/docs/python/
http://cobra-language.com/docs/quality/

No, these documents are too high level for that degree of detail.

[helium]

Either it should follow the normal rules from mathematics that many people know or it should completely disallow mixing and and or without parenthesis. So

Code: Select all

foo and bar or baz and qux

either should mean

Code: Select all

(foo and bar) or (baz and qux)

(thats what my brain immediately makes out of this) or it should be a compile time error and should force you to use parenthesis.