functionend ignored
John W. Eaton
jwe at octave.org
Fri Jul 17 11:06:06 CDT 2009
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
More information about the Bug-octave
mailing list