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

[Michael Leitner]

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

I was talking about your comment #3, which I read as your suggestion on an
improvement of the documentation assuming the behaviour is intended and should
stay as it is. Under this assumption my comment is to be understood. My claim
is that the statement "Unary operators always group from inside to outside" is
both intended and also describes the current behaviour. Yes, it is not
explicitly stated in the documentation, thus there is room for improvement.

You are correct, my statement "Unary operators always take precedence before
binary operators" ignores the relation between prefix increment/decrement and
exponentiation. The fact that the former takes precedence leads to 


a=1;
b=1;
++a^b


resulting in an error (because a^b is 1 and not an l-value) instead of 2
(which would result if the increment was evaluated first). But of course 


a=1;
b=1;
a^++b


does not give an error, because here the increment is evaluated first. The
reason is that an operator can of course only be evaluated when its arguments
have been evaluated, which is a meta-rule that takes precedence over the rules
of precedence. And note that also in the languages cited by you, it is no
question that operator precedence is always to be understood as where
parentheses are to be set, and not as how operators are to be permuted (they
are never permuted). What you imply with your examples corresponds to
permuting the operators. So in this light I would even say that the
documentation is okay as it is (apart from the grouping of the postfix
increment/decrement, which I really do not understand). 


    _______________________________________________________

Reply to this item at:

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

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