parsing commands

[John W. Eaton]

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