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

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

[Octave-bug-tracker] [bug #60882] error parsing command syntax


From: John W. Eaton
Subject: [Octave-bug-tracker] [bug #60882] error parsing command syntax
Date: Tue, 24 Aug 2021 06:14:10 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Follow-up Comment #39, bug #60882 (project octave):

Rik: until recent changes, when executing code at the command line, Octave
checked whether a symbol was defined as a variable and if so, did not attempt
to parse a statement as a command-style function call.  I believe that is also
what Matlab used to do.  But now, for consistency in behavior, Matlab uses the
same syntax-only rules to parse statements.  It doesn't consult the current
workspace at parse time.  The "used as variable and later as function" message
happens after parsing is already done, at the time the code is executed.

I think the only question left is whether to handle our extended set of
operators (++, +=, etc.) specially or in a fully Matlab-compatible way when
parsing command syntax.  Since Matlab doesn't have += (for example), I believe
that an expression like


foo +=


is parsed as a command-style function call regardless of what follows the +=. 
If we do the same for Octave, then it is impossible to use += as an operator
unless the expression is written with no space after the identifier:


foo+=something    ## OP=
foo+= something   ## OP=
foo +=something   ## command-style function call
foo += something  ## command-style function call


That seems bad to me, so I left the special treatment of these operators in
Octave so that the only one that causes command-style function parsing is


foo +=something


similar to the way that both Octave and Matlab handle other binary operators
(i.e., only the "foo +something" is handled as command-style function
syntax).

Since ++ is a unary operator and + by itself is both a binary and prefix unary
operator, the rules are a little different.  In Matlab, the parsing of
expressions involving repeated + characters is a bit weird:


foo ++            %% command-style function call
foo ++ something  %% command-style function call
foo++something    %% expression: foo + (+something)
foo++ something   %% expression: foo + (+something)
foo ++something   %% command-style function call


See also

https://octave.discourse.group/t/parsing-command-style-function-call-syntax/1414/4

where I posted a test function to verify current behavior of Matlab and
Octave.  Note that in the results that Markus posted for Matlab, the "OK"
doesn't mean that Octave and Matlab behavior is the same, just that we know
what the behaviors are.  Looking at the function itself shows that there are
currently differences between  Octave and Matlab for the following operators:


@
\
~
.+
.-
.**
!=
**
++
--

all the OP= operators.


It would probably be fairly painless to phase out and eventually remove


.+
.-
.**
**


We are already eliminating the problem with backslash as a continuation
character outside of character strings.  I think we can make the behavior of @
and ~ compatible with Matlab.  Changing != (and !) to be compatible would be
very unpleasant.

Since ++ and -- are not binary operators anyway, we can get closer to the
Matlab behavior if we reject them as two-character tokens in some cases
depending on the surrounding context, return just '+' (or '-') from the lexer,
and continue parsing beginning with the next '+' (or '-') character from the
input stream.  That should provide compatibility with Matlab by parsing
expressions like "foo++something" as "foo + (+something)".


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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