should Octave be more strict about checking number of arguments?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

should Octave be more strict about checking number of arguments?

John W. Eaton
Administrator
Bug report 58695 raised the following issue.

Currently, Octave allows function to be called with more input or output
arguments than can possibly be used or created.  For example,

   function f (), end

may be called as

   f (1)

or

   x = f ()   ## You do get a warning here
   [1, f, 2]  ## But not here...

I think the original intent in Octave was to allow the call warn or
attempt to do something reasonable (if possible) when no outputs are
created.  So I could see a reasonable argument made for allowing this
kind of behavior but I don't know why I thought this was a good thing to
do and it seems reasonable to have the interpreter detect these types of
argument number mismatches automatically.

I think Matlab always throws an error if a function is called with more
input or output arguments than can possibly be used or generated so this
would improve compatibility somewhat.

Should we change Octave's behavior to match Matlab?  Always?  Just when
using --traditional mode?

jwe

Reply | Threaded
Open this post in threaded view
|

Re: should Octave be more strict about checking number of arguments?

siko1056
On 7/9/20 1:28 AM, John W. Eaton wrote:

> Bug report 58695 raised the following issue.
>
> Currently, Octave allows function to be called with more input or output
> arguments than can possibly be used or created.  For example,
>
>   function f (), end
>
> may be called as
>
>   f (1)
>
> or
>
>   x = f ()   ## You do get a warning here
>   [1, f, 2]  ## But not here...
>
> I think the original intent in Octave was to allow the call warn or
> attempt to do something reasonable (if possible) when no outputs are
> created.  So I could see a reasonable argument made for allowing this
> kind of behavior but I don't know why I thought this was a good thing to
> do and it seems reasonable to have the interpreter detect these types of
> argument number mismatches automatically.
>
> I think Matlab always throws an error if a function is called with more
> input or output arguments than can possibly be used or generated so this
> would improve compatibility somewhat.
>
> Should we change Octave's behavior to match Matlab?  Always?  Just when
> using --traditional mode?
>
> jwe
>


Previously, I tried to fix bug #58686, where a scenario showed up, that
should always make Octave follow the Matlab approach in this regard.

The short outline is, assert() can be called in two ways

   assert (expr)
   assert (val, expected)

Now I made a test like this with your example

   assert (f(1), 42)

Because f() returns nothing the call was (without warning or error)
interpreted as

   assert (42)  ==  assert (true)

and passed Octave's test suite en perfect, even my function did not work
at all.

Thus with silent argument ignoring it is easily possible to create super
trivial mistakes, which are a nightmare to detect and to debug as the
code grows and Octave's test suite is of no help then.

I vote to always follow the behavior of Matlab in this case or at least
to throw a warning.

Kai

Reply | Threaded
Open this post in threaded view
|

Re: should Octave be more strict about checking number of arguments?

John W. Eaton
Administrator
On 7/8/20 9:22 PM, Kai Torben Ohlhus wrote:

> On 7/9/20 1:28 AM, John W. Eaton wrote:
>> Bug report 58695 raised the following issue.
>>
>> Currently, Octave allows function to be called with more input or output
>> arguments than can possibly be used or created.  For example,
>>
>>    function f (), end
>>
>> may be called as
>>
>>    f (1)
>>
>> or
>>
>>    x = f ()   ## You do get a warning here
>>    [1, f, 2]  ## But not here...
>>
>> I think the original intent in Octave was to allow the call warn or
>> attempt to do something reasonable (if possible) when no outputs are
>> created.  So I could see a reasonable argument made for allowing this
>> kind of behavior but I don't know why I thought this was a good thing to
>> do and it seems reasonable to have the interpreter detect these types of
>> argument number mismatches automatically.
>>
>> I think Matlab always throws an error if a function is called with more
>> input or output arguments than can possibly be used or generated so this
>> would improve compatibility somewhat.
>>
>> Should we change Octave's behavior to match Matlab?  Always?  Just when
>> using --traditional mode?
>>
>> jwe
>>
>
>
> Previously, I tried to fix bug #58686, where a scenario showed up, that
> should always make Octave follow the Matlab approach in this regard.
>
> The short outline is, assert() can be called in two ways
>
>     assert (expr)
>     assert (val, expected)
>
> Now I made a test like this with your example
>
>     assert (f(1), 42)
>
> Because f() returns nothing the call was (without warning or error)
> interpreted as
>
>     assert (42)  ==  assert (true)
>
> and passed Octave's test suite en perfect, even my function did not work
> at all.
>
> Thus with silent argument ignoring it is easily possible to create super
> trivial mistakes, which are a nightmare to detect and to debug as the
> code grows and Octave's test suite is of no help then.
>
> I vote to always follow the behavior of Matlab in this case or at least
> to throw a warning.

I pushed the following changesets to default:

http://hg.savannah.gnu.org/hgweb/octave/rev/b0b80efecea1
http://hg.savannah.gnu.org/hgweb/octave/rev/5a07c798eb08
http://hg.savannah.gnu.org/hgweb/octave/rev/1dd765e54265

The first makes is an error to call a function with more inputs or
outputs than the function can accept or produce.  The second fixes
Octave functions and tests to avoid these errors.  The third change
fixes tests that expect an error to match the new "function called with
too many inputs/outputs" error message instead of the older "invalid
function call" error.

This change is probably too disruptive for stable, but applying it now
on default should give us time for testing before version 7 is released.
  If it causes too much trouble, we can generate a warning instead of an
error by default.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: should Octave be more strict about checking number of arguments?

mmuetzel
Am 12. Juli 2020 um 23:57 Uhr schrieb "John W. Eaton":

> I pushed the following changesets to default:
>
> http://hg.savannah.gnu.org/hgweb/octave/rev/b0b80efecea1
> http://hg.savannah.gnu.org/hgweb/octave/rev/5a07c798eb08
> http://hg.savannah.gnu.org/hgweb/octave/rev/1dd765e54265
>
> The first makes is an error to call a function with more inputs or
> outputs than the function can accept or produce.  The second fixes
> Octave functions and tests to avoid these errors.  The third change
> fixes tests that expect an error to match the new "function called with
> too many inputs/outputs" error message instead of the older "invalid
> function call" error.
>
> This change is probably too disruptive for stable, but applying it now
> on default should give us time for testing before version 7 is released.
>   If it causes too much trouble, we can generate a warning instead of an
> error by default.
>
> jwe
>
>

I agree that the default branch is the one for this kind of changes.
It's possible they cause existing code to fail. We should probably let people know about this change with a note in the NEWS file.

Markus

Reply | Threaded
Open this post in threaded view
|

Re: should Octave be more strict about checking number of arguments?

John W. Eaton
Administrator
On 7/13/20 3:10 AM, Markus Mützel wrote:

> I agree that the default branch is the one for this kind of changes.
> It's possible they cause existing code to fail. We should probably let people know about this change with a note in the NEWS file.

I added a note in the NEWS file.

jwe