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