octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: anonymous
Subject: [Octave-bug-tracker] [bug #54698] Precedence of call/indexing operator over transpose operator
Date: Mon, 15 Oct 2018 08:29:32 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:51.0) Gecko/20100101 Firefox/51.0

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

I now think that this thread should be closed and there is no need to compound
transpose operators.

I have found that the current behavior of Octave is related to a typical
shift-reduce parser generator like Bison. I have found this blog
<http://h14s.p5r.org/2014/10/shiftreduce-expression-parsing-by-douglas-gregor.html>
has a good explanation of such parsers. It is shown that in parsing
consecutive postfix operators the precedence rules are ignored. 

In the case of Prolog in addition to precedence level the user also should
define how operands of a operator are related to the operator and because
those relationships are restricted by the language so it operates less
flexible than Bison. I have found that Prolog Ciao works as expected but
Prolog SWI has a bug and Mathematica works similar to Octave. CafeOBJ has
implemented a more restricted precedence capability as of Prolog. 

Also in the case of C++ the language hasn't defined any precedence but it can
be deduced from rules of the grammar. In other words its grammar hasn't
ambiguity. Also all postfix operators have the same level of precedence and
all prefix operators have the same level of precedence and both groups have
higher level of precedence related to binary operators so in the case of
precedence it has less problems than MATLAB or Octave. In other words its
precedence relationships is independent of the parsing algorithm.

So I think that my proposed compound operators are suggestions to make the
precedence relationship independent of the parsing algorithm but because Bison
and its parsing algorithm are  sufficiently well-known there may be no need to
introduce such operators to prevent complication of the condition.
Thanks.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]