Re: function definitions in tests

[David Grundberg]

John W. Eaton wrote:
> On 19-Jan-2010, David Grundberg wrote:
>
> | I changed eval_string on purpose to disallow open function bodies on 
> | EOF. Open ends are IMHO a bad construct that are especially confusing 
> | when several functions are defined. I don't think application writers 
> | should rely on eval () allowing open ends.
>
> I agree that it would be better to have all "function" tokens matched
> by "endfunction", but your change to the test function broke tests
> that already ended with "endfunction", so I think it is best to
> restore the previous behavior until we decide what is the right thing
> to do.
>   

There are in the current tip about three %!function test blocks that 
ends with an end token.

Something has to be done about the fntests.m/test.m disparity. 
Reproducing. Goto revision 10131:30817aa3889a. In this revision 'test 
fsolve' at the prompt passes 1/6 (5 fails). Create a script file 
'foobar.m' containing something like:

test('/path/to/octave/scripts/optimization/fsolve.m', 'quiet', 1)

Then execute './run-octave foobar.m'. All tests passes. This may have to 
do with the script/file flags.

> | On the other hand, I think it's clear that %!function blocks are ended 
> | with their indention, they don't need an endfunction. If we allow an 
> | endfunction token, then we should reasonably also support this syntax:
> | 
> | %!function foobar()
> | %!  # indented function body
> | %!functionend
> | 
> | But this doesn't work well with test.m as it is now, because it reads 
> | indention, it doesn't analyse syntax.
>
> If you want to disallow EOF ending a function body in an eval string,
> then I think we should require that functions defined in tests have
> endfunction tokens rather than complicating the test code by changing
> it to do any more complex parsing of input than it already does.  But
> doing that would require a lot of changes, not only to tests in
> Octave, but also to tests in Octave Forge and likely lots of other
> code.  My guess is that it would not make users happy.  And they
> probably would also not like it much if we require them to *not* use
> "endfunction" when writing tests.
>
> In any case, I don't see the harm in allowing the end of an eval
> string to work the same as an end of file when parsing a function.
> What trouble does that cause?

About eval not allowing open ends. There is no problem. Just a matter of 
principle. As it isn't really practical to hold on to it for reasons you 
stated, it may as well be.

David