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: Thu, 27 Sep 2018 11:24:39 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:51.0) Gecko/20100101 Firefox/51.0

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

In my expriments I have found that Wolfram Mathematica, like Octave, applied
postfix operators at list for the example a++[[x]], form inside to outside.
I sent an email to Prof. Theodore S. Norvell
<https://www.mun.ca/engineering/about/people/theodoresnorvell.php> an
associate professor of Memorial University of Newfoundland because he has
designed an algorithm for precedent parsing named precedence climbing
<https://www.engr.mun.ca/~theo/Misc/exp_parsing.htm> and asked him to explain
what is the correct meaning of precedence providing the following examples:

So, I have found different programming languages treat precedence as
different concept.
For example if we define an operand "A" and two postfix operators
"OP1" and "OP2" and and setting OP1 to bind to its operand tighter
than OP2 and evaluating the following expressions:


A OP1 OP2
A OP2 OP1
A OP2 OP1 OP2


Here are the results of the expressions in some programming languages:


Expression        Result             Language                Type of
operators

A OP1 OP2         (A OP1) OP2
A OP2 OP1         Syntax error       Prolog(Ciao)            User defined
A OP2 OP1 OP2     Syntax error

A OP1 OP2         (A OP1) OP2
A OP2 OP1         (A OP1) OP2        Prolog(SWI)             User defined
A OP2 OP1 OP2     Syntax error

A OP1 OP2         (A OP1) OP2
A OP2 OP1         Syntax error       CafeOBJ                 User defined
A OP2 OP1 OP2     Syntax error

A OP1 OP2         (A OP1) OP2
A OP2 OP1         (A OP2) OP1        Wolfram Mathematica     Builtin


And his kindly response:

--Quote from Prof. Norvell--

Whether or not a program has a syntax error or not is usually a matter that is
decided by a language specification, reference, or standard.  So it's not for
me to say.  For example, in the case of Ciao, they claim to "support ISO
Prolog", but they also allow syntactic extensions. (Similar, I guess, to how
gcc supports ISO C, but allows extensions.) I'd hope that Ciao has some mode
where it rejects any program that the ISO standards says is improper and
correctly interprets every program that the ISO standards says is proper. 
(Similar to gcc with the -std=c11 flag.)

Anyway, another question might be why they don't all just accept all your
examples?  Let's say we have a binary operator # that is in between OP1 and
OP2 in precedence.
     A # B OP2 OP1
Should it be an error?  If not, how do you think it should be parsed?


I don't know how you answered those questions; but for me the interpretation
     ((A # B) OP2) OP1
makes me uncomfortable, since A # B OP1 would be parsed as A # (B OP1); and
the interpretation
     A # ((B OP2) OP1)
makes me uncomfortable, since A # B OP2 would be parsed as (A # B) OP2.  So,
if I were a language designer, I think I'd be inclined to make A # B OP2 OP1 a
syntax error. After all, the user can always supply parentheses and these will
almost always improve the code's readability.

And, if A # B OP2 OP1 is a syntax error,  shouldn't A OP2 OP1 also be a syntax
error?  Or to put that question another way: can you think of a simple rule
that would allow A OP2 OP1, but disallow A # B OP2 OP1?

In my article, I made unary "-" have a lower precedence than * and ^. That
meant that
   - a^2
means -(a^2).  But that leads to the odd case that a^-2 * b means  a^(-(2*b)),
so somehow * gained priority over ^.   To me that's weird and undesirable.  I
gave "-" lower precedence, not because I think it's a good idea, but because
it posed an interesting parsing challenge.

On the other hand suppose we have an if-then-else construct with low
precedence.  To me
       a ^ if x then c else 2*b
doesn't seem weird at all.  But it's not all that different from a^-2 * b
which does seem weird.

Language design is tricky.

Currently I'm designing a language that has no precedence or parsing issues at
all.  It saves a lot of mental effort.

--End Quote from Prof. Norvell--

    _______________________________________________________

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]