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