Re: Operator precedence tests show 3 failures

[John W. Eaton]

On 20-Mar-2011, Rik wrote:

| On 03/20/2011 01:42 AM, marco atzeri wrote:
| > On Fri, Mar 18, 2011 at 5:40 PM, Rik  wrote:
| >> 3/18/11
| >>
| >> I just checked in some tests for the Octave parser (test_parser.m in
| >> tests/).  The current parser shows 3 failures.  These are known, but until
| >> jwe gets a chance to modify his proposed patch be aware that your 'make
| >> check' will not run cleanly.
| >>
| >> --Rik
| >>
| > 
| > at least 1 seems obvious
| > -------------------------------------------
| > assert ([2, 3] .^ 2',[4; 9]) expected
| >    4
| >    9
| > but got
| >    4   9
| > Dimensions don't match
| > -------------------------------------------
| > 
| > the test should be:
| > 
| > assert ([2; 3] .^ 2',[4; 9]) expected
| > 
| > to match dimensions of argument and result
| > Marco
| > 
| Actually, the point is that exponentiation has higher precedence in Octave
| than the transpose operator.  This should be parsed as
| ([2, 3] .^ 2)'.  Instead it is parsed as [2, 3] .^ (2').  Transposing a
| scalar does nothing nothing so Octave returns a row vector where it should
| return a column vector.  The original bug report is here
| (https://savannah.gnu.org/bugs/?32533).
| 
| For Ben's point, we are not trying to match Matlab's equal precedence for
| transpose and exponentiation.

Are the precedence rules for Matlab documented somewhere?

| Octave has it's own table for precedence and
| exponentiation is the highest priority.  We merely want to follow our own
| rules and documented behavior.

With my propopsed patch, the two tests that are failing are

  a = 0;
  assert (---a, 1);

and

  a = 0;
  assert (!~a++, false)

For the first, I guess we are parsing this as

  --(-a)

so the error message about invalid lvalue makes sense.  Are you saying
that this should be parsed as

  -(--a)

?  If so, maybe it would be clearer in the tests to write it as

  a = 0; b = 0; assert (---a, -(--b))

If this is correct, then I think the problem is with the lexer, which
is preferring the longest match when generating tokens for the parser,
so it sees --- as -- -, not - --.  I suppose we can fix this with
additional lookahead.

For the second, it is apparently parsed as

  (! (~ a))++

Is that incorrect?  Is it supposed to be

  ! (~ (a++))

?  I'm not sure what the right fix is for this one.

jwe