Re: Changes to lexer invalidate documentation

[Rik]

John W. Eaton wrote:
> On 12-Apr-2009, Rik wrote:
>
> | The parser has changed and the new output is:
> | ---------------------
> | functon y = f (x) y = x^2; endfunction
> | parse error:
> | 
> |   syntax error
> | 
> | >>> functon y = f (x) y = x^2; endfunction
>
> This is valid through the ";", so I think the parser is doing the best
> it can.  For example, try this:
>
>   functon y = f (x) y = x^2;
>
> and you'll see
>
>   error: `functon' undefined near line 1 column 1
>
> So the syntax of this much is valid and the problem is that there is
> no function called "functon" available to call.  Then there is a
> syntax error when the parser sees "endfunction" as an expression by
> itself.
>
> | I would argue that this is less desirable than the old behavior.
>
> I think we're comparing different things.  With an older version of
> Octave, try
>
>   mark_as_command functon
>   functon y = f (x) y = x^2;
>
> and you should see a message similar to what the current Octave
> produces.
>   
> | indicating the error at the end of line it gives no clue where the real
> | problem lies.
>
> Octave doesn't try to guess that the functio name is misspelled, so
> unless we decide to implement something like that (I'd rather not)
> then I think it is the best we can do.
>   
The semicolon is used to indicate an end of line (and please don't print
the results of the previous command) or as a new row indicator in a
matrix.  The original example is,

functon y = f (x) y = x^2; endfunction

which I would think would parse as 
 A ; B
where A = 'functon y = f (x) y = x^2'
and B = 'endfunction'.

If I follow your lead and type line 'A' individually I get a nice clean error 
message, but when I follow it with 'endfunction' I get the generic parse error. 
 Should the parser really have a forward dependency on what lies beyond the 
semicolon in this case?  The parser should be able to tell it is not in a 
matrix so the only interpretation for the semicolon is to end input here.  It 
can then evaluate statement 'A' as if it were typed alone and produce the 
correct error message.     

> | If the new
> | behavior can't be corrected it might be better to find a new error
> | example which shows off the parser in a better light.
>
> Yes, I agree that the behavior of this example is too complex for an
> introduction to error messages.  It would be better to have something
> simpler.
>   
Okay, I'll try and find a different, simple example for the documentation.

--Rik