functionend ignored

David Grundberg individ at acc.umu.se
Fri Jul 17 11:22:44 CDT 2009


John W. Eaton wrote:
> 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.
>   

Ok. FYI, subfunctions without ends passes with no warning in Matlab 
7.7.0. Just checked now and there is no warning in the editor either.

> | 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.
>   

I was making a concrete statement about the example. You are correct.

> | 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
>   

Ok.

Thanks for your answers,
David


More information about the Bug-octave mailing list