[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Parsing "commands"
From: |
Søren Hauberg |
Subject: |
Re: Parsing "commands" |
Date: |
Mon, 16 Feb 2009 22:21:21 +0100 |
son, 15 02 2009 kl. 23:50 -0500, skrev John W. Eaton:
> On 15-Feb-2009, Soren Hauberg wrote:
>
> | lor, 14 02 2009 kl. 20:12 -0500, skrev John W. Eaton:
> | > Although I see all tests passing with this change, it is still quite
> | > experimental and probably not quite right yet, so I have not checked
> | > it in. But it would help for it and the previous lexer/parser patch
> | > to get some additional testing.
> | >
> | > Comments?
> |
> | My intuition tells me that it's fairly hard to test such a change. So, I
> | think the best way to test it, is to use it in "real life" situations.
> | So, I'd say, commit the changes, to get more wide testing.
>
> OK, you're probably right. I checked these changes in.
Okay, so I'm playing a bit around with a recent checkout. I've created
the following function
function retval = cmd (varargin)
str = sprintf ('%s ', varargin {:});
retval = length (str);
endfunction
I see the following non-compatible situations
** Octave **
octave:4> cmd - 1
parse error:
syntax error
>>> cmd - 1
^
** Matlab **
>> cmd - 1
ans =
-1
** Octave **
octave:11> cmd + - 1
ans = 1
** Matlab **
>> cmd + - 1
ans =
-1
** Octave **
octave:13> cmd += 2
parse error:
syntax error
>>> cmd += 2
** Matlab **
>> cmd += 2
ans =
5
But these are fairly odd situations. In general things seems to work
very well.
Soren