· Nov 26, 2021

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 ?


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

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 ?

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 ?

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

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.

as official documentation tells you:

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



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.

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!