IRIS and the order of operations: 12+23=12 but (12)+(23)=8; is there a setting somewhere to adopt the same conventions as everyone else in the world ?

Question

Question

Michel Liberado · Nov 26, 2021

Hi,

I wonder why IRIS seems to have its on way to deal with order or operations such as the example in the title. This affects regular arithmetic operations but of course conditions in various statements.

Even after years of COS development, I still get caught by these tiny frustrating details and it is absolutely annoying when you are writing APIs that some some maths.

Here is an example:

The last example is from here.

But, if you use any other calc:

With Google calc:

Product version: IRIS 2021.1

Discussion (13)2

Log in or sign up to continue

Michel Liberado · Nov 26, 2021

We are looking forward for Embedded Python ! About the mindset|languages, don't be rude please ! 😚. Whenever a new developer comes in and jumps into ObjectScript, you don't necessarily tell him about this very rule exception when writing arithmetic nor does he think that he should read the documentation SQL/Using SQL/... whilst it's not trivial that is is related. I was just asking about a setting that would make me confident when we deliver our platform to future developers.
I always format my expressions with "(" but for some people this is just some coding style...

3 0

score 4 · Answer 1 · 2021-11-26T04:19:50-05:00

Each programming language has his own operator precedence and they may differ

https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GC...

score 1 · Answer 2 · 2021-11-26T04:30:31-05:00

Operator precedence in ObjectScript is strictly left-to-right; within an expression operations are performed in the order in which they appear. This is different from other languages in which certain operators have higher precedence than others

I am fine with each language having its own operator precedence, but, is there a setting somewhere, even hidden or activable with some obscur guru command to have the same as pretty much everyone else ?

score 1 · Answer 3 · 2021-11-26T04:47:01-05:00

John Murray · Nov 26, 2021

I don't think there is any such setting, and I have been using InterSystems products for a long time.

1 0

score 2 · Answer 4 · 2021-11-26T05:06:11-05:00

You wrote, citation, "I am fine with each language having its own operator precedence, ..." then where is the problem?

In case, you talk about SQL, see this Article (scroll down to Operator Precedence)

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...

score 3 · Answer 5 · 2021-11-26T05:38:00-05:00

Even the possibility of changing this elementary rule after 60+years
has the power and the risk of breaking millions of lines of code worldwide.
It's for people like you that are not willing to accept these rules that
the introduction of Embedded Python is encouraged.

With the same mindset,
you may demand to revert from Italian, French Spanish, Portuguese
to pure Latin as spoken by Cesar. Or for French to Occitan ?

score 0 · Answer 6 · 2022-11-28T18:24:53-05:00

Hi Michel,
Good subject, i like to question the things we are used to, but look strange to the outside world.
I would welcome the possibility to change the precedence to something more 'standard'. When i taught Object Script courses, the left-to-right precedence was always the first thing i mentioned, and it always blew the heads of my students.
Unfortunately, the option is not present, and even if there could be ways to implement such an option by InterSystems (e.g. as a method keyword to alter the precedence), the general behaviour will have to default to the current precedence to not break existing code.
Maybe editors like vs-code can issue warnings when operators are used without brackets in Object Script.

score 0 · Answer 7 · 2022-11-29T07:15:39-05:00

Not only external code, but IRIS itself would probably stop working ;-)
But setting it as a ClassDefinition option should be feasable, then the class compiler could convert 'standard' precedence to ObjectScript precedence.

score 1 · Answer 8 · 2021-11-26T06:46:00-05:00

as official documentation tells you:
https://docs.intersystems.com/iris20211/csp/docbook/DocBook.UI.Page.cls?KEY=GSQL_langelements#GSQL_langelements_ops_precedence

 
USER>SET status=$SYSTEM.SQL.Util.SetOption("ANSIPrecedence",1,.oldval)
 
USER>do $system.SQL.Shell()
SQL Command Line Shell
---------------------------------------------------

[SQL]USER>>SELECT 1+2*3+4*5
1.      SELECT 1+2*3+4*5
Expression_1
27
^^^^-----------------------------------------------
[SQL]USER>>q
 
USER>SET status=$SYSTEM.SQL.Util.SetOption("ANSIPrecedence",0,.oldval)
 
USER>do $system.SQL.Shell()
SQL Command Line Shell
---------------------------------------------------
 
[SQL]USER>>SELECT 1+2*3+4*5
3.      SELECT 1+2*3+4*5
 
Expression_1
65 
^^^^----------------------------------------------
[SQL]USER>>

.

score 3 · Answer 9 · 2021-11-26T07:02:52-05:00

Hello

Older professionals can confirm it, but this operation ordering premise is older than the InterSystems product. It comes from the origin of MUMPS. So I don't think it's something InterSystems can or should change.

When I discovered this feature of language, I decided that all my codes involving numerical calculations should always be formatted with "(", determining precedence, even if precedence is natural to language. And I do it that way regardless of language.

For example, in COS this calculation would be natural:

Write !,10 + 10 * 10
USER> 200

But I would always code like this:

Write !,( 10 + 10 ) * 10
USER> 200

This way the code will be readable even for "Non MUMPS" coders, and this piece of code could even be migrated to other languages without problems.

score 2 · Answer 10 · 2022-11-28T10:34:26-05:00

I have always over-used parentheses for this reason.

It's also very important when using logical operators:

1=0&&1=0 -> 0&&0=0 -> 1=0 -> 0

(1=0)&&(1=0) -> 0&&0 -> 1

score 3 · Answer 11 · 2021-11-26T11:29:23-05:00

I'm no particular fan of this aspect of the language, but changing it as an "option" (by namespace?, routine?) would be a nightmare for maintenance. :-) Only recently fell foul of it with code like: IF type="X"!type="Y" ... that can never be true.

You could argue that it is at least very simple to understand. Just one rule to remember - left to right, except for brackets - rather than a precedence order for every single operation you might use!

score 1 · Answer 12 · 2022-12-01T11:18:12-05:00

Now, with Python, you can choose your preferred way of operator precedence

USER>w 1 + 1 * 2 4 USER>do ##class(%SYS.Python).Shell()

>>> print(1 + 1 * 2) 3

IRIS and the order of operations: 1*2+2*3=12 but (1*2)+(2*3)=8; is there a setting somewhere to adopt the same conventions as everyone else in the world ?

IRIS and the order of operations: 12+23=12 but (12)+(23)=8; is there a setting somewhere to adopt the same conventions as everyone else in the world ?