bugGNU Octave - Bugs: bug #56881, Command line functions are visible...

 
 

bug #56881: Command line functions are visible from m files

Submitter:  None
Submitted:  Wed 11 Sep 2019 01:32:49 PM UTC
   
 
Category:  Interpreter Severity:  1 - Wish
Priority:  3 - Low Item Group:  Feature Request
Status:  Postponed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Open Release:  * 5.1.0
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 16 Sep 2019 04:23:32 PM UTC, comment #14: 

Regarding comment #13, "I see the command line workspace as an anonymous script file that is placed in the current directory and it should behave just as a script file."

That is the current behavior.  The PATH variable usually begins with '.' (current directory followed by various other directories with libraries of functions.  Because the current directory is listed first, any function files there will override (shadow) files placed elsewhere.  Octave command line functions are higher in precedence than those on the search path so they act implicitly as though they were on the search path, but listed before even the current directory.

"The keyword global currently has this capability . It can be used to pass function handles."  This is because anonymous functions are variables and they have variable scoping.  Hence, you can use "global" to pass the anonymous function in to an m-file.  If we really want to enforce "local" command-line functions then it would be useful to have a way of bringing those functions in to a different scope.

That might be through a specific keyword, like global, but it could be done other ways as well.  At the moment, visibility of functions is controlled by the PATH variable.  If we wanted to restrict command-line functions to a specific scope we might imagine dual-purposing the PATH variable and having entries that represent workspaces.  The current workspace would have a default entry at the top of the PATH so that local command line functions would be executed in preference to other functions.  But then, if a programmer desired, they could add additional workspaces, like the base workspace or parent workspace, as entries in the PATH, and have very fine-grained control over the search order.

That sounds like a lot of work, but it could be done.

Rik <rik5>
Group administrator
Mon 16 Sep 2019 03:40:01 AM UTC, comment #13: 

I see the command line workspace as an anonymous script file that is placed in the current directory and it should behave just as a script file. It may contain multiple function definitions and they don't shadow other functions on the path.

> "I was suggesting something like an opt-in, in the same way a programmer has to use the keyword global, if they really want to import a command line function."


The keyword global currently has this capability . It can be used to pass function handles.

Anonymous
Fri 13 Sep 2019 09:13:09 PM UTC, comment #12: 

I think the end state--capricious code that executes variably and where it is difficult to debug the root cause--is to be avoided.

I was suggesting something like an opt-in, in the same way a programmer has to use the keyword global, if they really want to import a command line function.

Issuing a warning is also fine with me because it makes it obvious that there is a potential issue, and it is up to the programmer to make the judgment call.

Matlab, as usual, is of no help.  The following script is allowed (i.e., it runs) and it emits no warnings, and the output is "Hello", not 0.14112.


1;
which sin
sin (3)

function y = sin (x)
    disp ('Hello');
end


I don't think the situation we are trying to address comes up very often so I would only modify things if it were easy.  But, assuming it was easy, it would be nice to get a shadowed warning message whenever a function is added to the symbol table.


Rik <rik5>
Group administrator
Fri 13 Sep 2019 08:55:49 PM UTC, comment #11: 

As the bug marked as wont fix if there is a will to fix it would be simple.

1. Adding a method named bool is_cmd_line_function(); to "octave_user_function" or "octave_function" class
2. in the tree_evaluator::visit_function_def mark the function as cmd_line.
3. in fcn_info::fcn_info_rep::xfind if and only if the current function is a cmd_line function  search for command line functions


Anonymous
Fri 13 Sep 2019 08:51:34 PM UTC, comment #10: 

Mike: similarly, should we try to warn when the loadpath changes and functions are added to the path that will shadow or be shadowed?  WDMD?

John W. Eaton <jwe>
Group administrator
Fri 13 Sep 2019 08:31:15 PM UTC, comment #9: 


> I don't see how it is any different for functions defined in files or at the command line.


That's my opinion also.

Would this be resolved with a new warning when a command line function is defined that happens to shadow a function on the load path?

What about when a command line function does not shadow a function, but then a directory is added to the load path with a function that is already shadowed?

Mike Miller <mtmiller>
Group Member
Fri 13 Sep 2019 07:12:21 PM UTC, comment #8: 

Isn't it also possible for functions defined in files to shadow built-in functions or other functions in the path?  Doesn't that happen whether these "evil" functions are found elsewhere in the path or in the current working directory?

For example, if I place the following function in my current directory and execute "sombrero", I get "HAHAHA!" error message instead of a pretty plot.


function surf (varargin)
  error ("HAHAHA!");
endfunction


Isn't this just one of the long-standing problems with Matlab that TMW has been trying to fix for a couple of decades now by introducing things like subfunctions, private functions, nested functions, packages, and classdef objects?

I don't see how it is any different for functions defined in files or at the command line.

I thought it was supposed to be possible to even overload + for doubles by adding an @double/plus.m file in Matlab.  Is that no longer true?  Or am I mistaken and that was never true?

Does Matlabl really limit function resolution inside core functions to only other built-in or core functions?  Does it also do that for toolbox functions?  If so, what are the rules?  Are they clearly documented somewhere?

We do warn when built-in functions are overloaded by user-defined functions, but only when a directory is added to the load path, not when a file is added to a directory that is already in the load path.  Maybe we could expand the warning to happen any time a function is loaded that will shadow another function in the path?  I don't know, that might be annoying?  We could certainly do it for command line functions.

John W. Eaton <jwe>
Group administrator
Fri 13 Sep 2019 06:00:16 PM UTC, comment #7: 

I'm not saying it is good or bad, but the behavior is different from how variables are treated.  Variables also exist in namespaces and if you want access to them you need to take explicit measures such as using "global" or evalin().

A command line function feels to me like a temporary, local object of the workspace where it was defined, and hence I would assume that visibility is not exported by default.

I think there are plenty of easy ways around this, including using 'clear -f' before running scripts if you are very concerned about aliasing of function names.

Because command-line functions are not part of Matlab, we can do whatever we want, but we still may surprise some users who port scripts and get strange errors because of name aliasing.

Rik <rik5>
Group administrator
Fri 13 Sep 2019 03:41:32 PM UTC, comment #6: 

The Octave function precedence is documented here:

https://octave.org/doc/v5.1.0/Function-Precedence.html

Making changes in fundamental language features might really mess up the work of many programmers relying on this. Thus marking as won't fix and leaving this item open for now to get more comments on this.

If you want to be sure to use a "native" Octave function version, make use of


builtin ("native_function_name", arg1, ...);


Kai Torben Ohlhus <siko1056>
Group Member
Fri 13 Sep 2019 10:58:11 AM UTC, comment #5: 

I believe that function files are more important than command line functions. Function files are placed in the persistent storage while command line functions are just temporaries. I see function files as the building blocks of Octave. As they are documented they should have consistent behavior. Their expected behavior should be determined by their writer not their user. When we as users define a command line function to (intentionally/ unwantedly) shadow other functions we change the expected behavior of function files so it leads to instability of the system. Such a use case may be useful for debugging purposes but shouldn't be adopted as an idiomatic and ordinary use.

Anonymous
Fri 13 Sep 2019 05:33:46 AM UTC, comment #4: 

So are you saying that your use case and your opinion is that command line functions are throwaway, less important than function files? And that function files are somehow more solid or permanent than command line functions? Does that summarize the distinction in your view between the two cases?

In my opinion, in your example, if the user defines a command line function called "test_fcn_2", then they did intend to shadow the function file "test_fcn_2.m", that seems very reasonable to me.

Mike Miller <mtmiller>
Group Member
Fri 13 Sep 2019 04:27:53 AM UTC, comment #3: 

For the example I created a directory structure as below also attached. "testpath" has two sub folders "path1" and "path2".
In each of three folders there is a .m file.


\---testpath
    |   test_fcn_0.m
    |
    +---path1
    |       test_fcn_1.m
    |
    \---path2
            test_fcn_2.m
           

"test_fcn_0" calls "test_fcn_1" and then "test_fcn_1" calls "test_fcn_2" and test_fcn_2 displays "Hello".

test_fcn_0 ==> test_fcn_1 ==> test_fcn_2 ==> disp("Hello")


%test_fcn_0.m
function test_fcn_0
  test_fcn_1
end

%test_fcn_1.m
function test_fcn_1
  test_fcn_2
end

%test_fcn_2.m
function test_fcn_2
  disp("Hello")
end


Using addpath I pushed all three folders on the path then in the command line I created a function "test_fcn_2" that has the same name as the function that prints "Hello" but the command line version displays "Evil".


% command line function
function test_fcn_2
  disp("Evil")
end


In the command line  type

 > test_fcn_0
 
and it shows "Evil". The command line function shadows the function on the path.

Now I type

 > clear test_fcn_2
 
It clears the command line function and again running test_fcn_0  it shows "Hello".

A user usually creates a command line function because it is handy and there is no need for it to be saved in a file. But I'm in doubt if a user wants to create a command line function to deliberately shadow other functions on path. In other words What users should do if they want to use command line functions but they don't want to shadow other functions ? Possibly they can choose a distinct function name to prevent name clash but for it they should remember/list all the function names on the path. I mean the evil shadowing shouldn't be as simple as creating a command line function. As in the comment #2 noted there are more difficult ways to do it.
When I create a command line function it can affect all the functions on path but when I create a .m file in the current directory ( that isn't on the path) it can affect only those functions that have been saved in the current directory.

Anonymous
Thu 12 Sep 2019 07:35:47 PM UTC, comment #2: 

This seems like a feature of the language to me and not a bug. Any function, whether on the load path or on the command line, is defined in the same shared global namespace.

If a user creates a 'max.m' function or script file, it shadows the built in function 'max'. The same is true for defining a command line function 'max'. I don't see a difference between these two scenarios. The best advice is always to avoid shadowing standard function names.

Can you explain a use case that makes this a more severe problem for command line defined functions?

Mike Miller <mtmiller>
Group Member
Wed 11 Sep 2019 01:40:16 PM UTC, comment #1: 

The only exception is script files that are executed from the command line. They can see command line functions.

Anonymous
Wed 11 Sep 2019 01:32:49 PM UTC, original submission:  

Currently functions that are defined in the command line are visible from .m files . The outcome is that command line functions can shadow functions on the path. So the behavior of a .m file function , that should be relatively stable, depends on whether a function  is defined on the command line or not that to me isn't reasonable.
So my suggestion is that command line function should see each other and any other type of functions but they shouldn't be visible from non command line functions.


Regards!

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #47493:  testpath.zip added by None (1KiB - application/x-stuffit - attachment for commant #3)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-10-26 siko1056 StatusWont Fix Postponed
    2019-09-13 siko1056 StatusNeed Info Wont Fix
    2019-09-13 None Attached File- Added testpath.zip, #47493
    2019-09-12 mtmiller Severity3 - Normal 1 - Wish
        Priority5 - Normal 3 - Low
        StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code