[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
parsing commands
From: |
John W. Eaton |
Subject: |
parsing commands |
Date: |
Fri, 17 May 2013 18:04:16 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11 |
My recent changes to the lexer and parser screwed up parsing commands in
some cases. For example, here's a bug report about one case:
https://savannah.gnu.org/bugs/?38988
For compatibility with Matlab, the lexer tries to recognize commands
using rules similar to the ones stated here:
http://www.mathworks.com/help/matlab/matlab_prog/command-vs-function-syntax.html#bqlqlwc
As I understand it, the rules only apply if the identifier is at the
beginning of a statement and can not otherwise be determined to be a
variable (is either currently defined as a variable or has appeared on
the left hand side of an assignment statement).
Then, if the identifier is followed by an assignment operator (for
Matlab, that is only '=') or an open paren or brace then it is not a
command, regardless of spacing around the token that follows the
identifier. So, for example,
foo =bar
is an assignment, not a command. For other operators, spacing
matters. For example,
foo./bar
foo./ bar
foo ./ bar
are all binary operations but
foo ./bar
is a command.
For Octave, we have to decide what to do for the operators that are
unique to Octave. That includes all op= assignment operators, ++, and
--. Since Matlab does not have --,
foo --
will be a command. But for Octave, that could be a decrement
operation.
Since the '--' in
foo --bar
doesn't make sense as a decrement operator, I will fix that much and
close the bug report. But should we also accept -- as a command
argument even if it is at the end of a statement?
What about all the op= assignment operators? In Matlab, all of them
would be parsed as commands if they are preceded by a space, or as
syntax errors otherwise. For example, things like
x -= foo
x -=foo
are commands in Matlab because in both cases the '-' operator is
not followed by a space. Something like
x-=foo
would be a syntax error because '-' followed by '=' doesn't make
sense. In Octave, -= could be an assignment operator.
So how far do we want to go for compatibility?
I suspect few people will want to eliminate the ++, --, and op=
operators entirely just for Matlab compatibility, but if we don't
parse at least some of these the same as matlab, then I'm sure we are
going to see more bug reports like the one linked above.
jwe
- parsing commands,
John W. Eaton <=