[Top][All Lists]

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

[Octave-bug-tracker] [bug #56881] Command line functions are visible fro

From: Rik
Subject: [Octave-bug-tracker] [bug #56881] Command line functions are visible from m files
Date: Mon, 16 Sep 2019 12:23:32 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko

Follow-up Comment #14, bug #56881 (project octave):

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.


Reply to this item at:


  Message sent via Savannah

reply via email to

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