[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #43299] anonymous function arguments may be sh

From: Mike Miller
Subject: [Octave-bug-tracker] [bug #43299] anonymous function arguments may be shadowed by function names
Date: Thu, 25 Sep 2014 12:23:35 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36


                 Summary: anonymous function arguments may be shadowed by
function names
                 Project: GNU Octave
            Submitted by: mtmiller
            Submitted on: Thu 25 Sep 2014 08:23:34 AM EDT
                Category: Interpreter
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Incorrect Result
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: dev
        Operating System: Any



This seems to be a subtle bug in the way that names are resolved in the
definition of an anonymous function. If the name of an anonymous function
argument is also the name of a function (command-line, m-file, or oct-file),
the name may resolve to the function rather than the argument.

Some examples:

fn = @(x) x;
fn (1)

This seems to work fine even if x is defined as a function.

fn = @(x) x(:);
fn (1)

This anon function definition attempts to resolve x as a function first, and
only if it doesn't exist does it work as the argument to the anon function.
The name lookup happens when the function is defined, not when it is called.
So if I create an invalid oct-file for example,

system ("echo > x.oct");
fn = @(x) x(:);
error: caught execution error in library function

the error is thrown when the function is being defined.

This can break code in Octave itself if an anonymous function is defined with
an arg like "x" and the user creates a function also named "x". See for
example bug #43237.

According to Ben, Matlab correctly handles this case, the anonymous function
argument name always takes precedence.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]