[Octave-bug-tracker] [bug #54698] Precedence of call/indexing operator over transpose operator

[anonymous]

Follow-up Comment #5, bug #54698 (project octave):

"Isn't this unnecessarily complex?"

The rules related to precedence, associativity, side effects and the order of
evaluation are unavoidably complex. It is sufficient to have a look at the
documentation of the languages, like c++ and java, that have standardization.
The point is that the MATLAB has more restricted problems related to Octave
because it doesn't allow indexing on a temporary and doesn't have operators
like += or ++.

"Unary operators always group from inside to outside"

This statement neglects the precedence of operators. It should be modified to
Unary operators always group from inside to outside if they have the same
level of precedence.The transpose operator and the call operator don't have
the same level of precedence, due to higher precedence of () operator it
should be evaluated before ' operator.

"Unary operators always take precedence before binary operators"

The only exception is the power operator that has higher precedence than
‘+’ ‘-’ ‘++’ ‘--’ ‘~’ ‘!’  operators and has equal
precedence related to .' and ' operators.bug 54491
<https://savannah.gnu.org/bugs/?54491>

"Is an explicit rule about operator collapsing actually needed?"

Consider the following example:


A'''(X)(Y)


If we don't use the collapsing rule and only use the compound '() operator
because the operators '() and () have higher precedence than ' operator then
the expression is translated to:


A'(X)(Y)''


That is not the intended behavior.

I should correct my previous opinion to:
Collapsing rules say that consecutive transpose operators, regardless of what
actually is done internally, should be treated as one operator.
For the builtin numeric types, for the purpose of optimization, we can
internally reduce the consecutive transpose operators to 9 new compound types
but for the user-defined transpose/ctranspose operators the operators should
not be collapsed and should be executed consecutively but the user should be
informed that they are treated as one operator and we may have infinite
compound operators  like ''''() and .'.'''().

Instead of those complicated rules we can respect the current documentation,
fix the bug and instead of writing a'(:) we can write (a')(:) .(Changing all
instances of such use to parenthesised use)

I think the increment operator may divert the current discussion and it
potentially is subject of multiple new bug reports!

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?54698>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/