functionend ignored

[Sergei Steshenko]

--- On Fri, 7/17/09, John W. Eaton <jwe at octave.org> wrote:

> From: John W. Eaton <jwe at octave.org>
> Subject: Re: functionend ignored
> To: "David Grundberg" <individ at acc.umu.se>
> Cc: bug at octave.org
> Date: Friday, July 17, 2009, 9:06 AM
> On 17-Jul-2009, David Grundberg
> wrote:
> 
> | Function tree must be rearranged (oboy) to
> | 
> |   toplevel.functions = {foo, bar, baz}
> |   foo.functions = {}
> |   bar.functions = {}
> 
> 
> | As stated previously, I think files missing all
> endfunctions should 
> | print a warning or some diagnostic.
> 
> And I'm still saying that the warning should be off by
> default,
> otherwise we will likely see complaints about it becuase
> Matlab does
> not issue a warning in this case, and I suspect there is a
> lot of code
> with subfunctions that is written this way.  As I
> recall, in the old
> days, Matlab did not use "end" to mark the end of a
> function at all,
> so EOF or a new function keyword was the only way to
> indicate the end
> of a function, and extra end tokens were just
> ignored.  But I can't
> remember for sure, and now have no way to test.
> 
> | Notice that if we had read an endfunction or two before
> the EOF in case 
> | B, then we issue an error. (not enough endfunctions)
> 
> I think the rule is that there should either be
> 
>   no end tokens matching function keywords OR every
> function keyword
>   must have a matching "end"
> 
> Anything else is an error, because then it is impossible to
> determine
> whether the extra functions in the file are subfunctions or
> nested
> functions.
> 
> | Correct me if I'm wrong, but I think the lexer shouldn't
> need to know 
> | what level of indention we are parsing. I don't
> understand why the lexer 
> | has been written this way, with end_tokens_expected? To
> me, the only 
> | situation where the lexer needs to mark 'end' as a
> non-keyword is in 
> | object indexing.
> 
> I don't remember why I chose to do things this way. 
> If you have a
> better way, then propose a patch.
> 
> jwe
> _______________________________________________


I think it's the case when sloppy Matlab code should be fixed, i.e.
the case of intentional bug-to-bug incompatibility with Matlab.

What I've read so far looks very convoluted, and if the developers want
to spend their effort, they better spend it implementing missing Matlab
functionality (like nested functions).

I mean that missing 'end'/'enfunction' should not just cause a warning, but
be considered an error. It is really easy to add missing 'endfunction'.


Regards,
  Sergei.