Potentially misleading order of operations for operator **

[alexandrebouchard]

The XExpression 2 * 3 ** 4 generates Math.pow((2 * 3), 4);; however, the universally accepted mathematical order of operation would be 2 * Math.pow(3, 4). This is also the order used in scientific computing oriented languages e.g. python and Julia.

[cdietrich]

https://www.eclipse.org/xtend/documentation/203_xtend_expressions.html#operators

Says ˋ*ˋ and ˋ**ˋ have the same order level. Am not sure if we can change this afterwards. @svenefftinge @szarnekow what do you think

[svenefftinge]

While I don't expect much code outside relying on the 'wrong' precedence. A change will for sure break many / all xbase users. Therefore I'd vote for keeping it as is. Such precedencies are not well known so it is good to use parenthesis for less informed readers anyways.

[szarnekow]

It’s probably worthwhile to add a validation warning for these binary expressions with an unexpected precedence. We could also fix it in Xtend without breaking Xbase clients but that may become a (rare) source for confusion.

[gallandarakhneorg]

I think Issue eclipse/xtext#2245 is related: a precedency problem between the cast operator and the minus operator. It's leading me to say that the operator precedency within Xbase should be reviewed and fixed carefully.

I'm not agree with @svenefftinge regarding the definition of the operator precedencies. Well known languages provide power and cast operators that have well-known precedencies. Take a look on PHP, FORTRAN, MatLab, etc. and you could find clear definition of the operator precedencies for the operators we are discussing about. My point is that Xbase does not follow the usual precedencies for several operators (power and cast operators for examples).

I vote for the proposal of @szarnekow: a fix of the issue and possibly a validation warning for users of the older Xbase. Letting the code of Xbase as-is is a major issue for Xbase that may lead to the move of the Xbase users to another technology or to discard Xbase when selecting a technology for a new project.

Fixing within Xtend is not enough for me; because it gives to the Xbase users the following message: Xbase has bugs that you must fix by yourself within your DSL. That's not a good message to give to the Xbase users from my point of view.

[gallandarakhneorg]

After Googling a little, I could propose the following precedence table for Xbase.

Inspiration sources:

• Java operator precedence
• C++ operator precedence
• Python operator precedence

Xbase precedence table from lower priority to higher priority:

Operator	Description
||	Boolean OR
&&	Boolean AND
==, !=, ===, !==	Equality
>=, <=, <, >, <>, instanceof	Relational
.., >.., ..<, ->, =>, ?:	Construction operator: range, pairs, etc.
>>, <<, >>>, <<<	Shifting operators
+, -	Addition and subtraction
*, /, %	Multiplication, division, modulo
as	Cast operator
**	Exponentiation
!, +x, -x	Negation, Positive, negative
++, --	Postfix operators

This table does not corresponds to the current grammar of Xbase.

[gallandarakhneorg]

Changes to be applied within the Xbase grammar are:

XMultiplicativeExpression returns XExpression:
    XCastedExpression (=>({XBinaryOperation.leftOperand=current} feature=[jvm::JvmIdentifiableElement|OpMulti]) rightOperand=XCastedExpression)*;

OpMulti:
    '*' | '/' | '%';

XCastedExpression returns XExpression:
    XExponentExpression (=>({XCastedExpression.target=current} 'as') type=JvmTypeReference)*;

XExponentExpression returns XExpression:
    XUnaryOperation
    (=>({XBinaryOperation.leftOperand=current} feature=jvm::JvmIdentifiableElement|OpExponent]) rightOperand=XUnaryOperation)*;

OpExponent:
    "**";

XUnaryOperation returns XExpression:
    {XUnaryOperation} feature=[jvm::JvmIdentifiableElement|OpUnary] operand=XUnaryOperation
    | XPostfixOperation;

OpUnary:
    "!" | "-" | "+";