The text below is not what I insist on to implement
a mere example of existing solution in another soft
Suppose in R pkg1 and pkg2 have the same named fun()
Suppose one has executed
library(pkg1) # equivalent of include a_pkg.gfn
In this case running fun(args) is running fun prom pkg2,
since library(pkg2) was executed later
"long syntax" is used to avoid ambiguity
In this situation
pkg2::fun(args) is the same as fun(args)
To run fun() from pkg1 only "long version"
The idea is to have a possibility to use
"long" syntax alongside with the "short" one
The realization of the "long syntax"
should relay upon minimization of coding
I do not know what will be easy to realize
Since no names can start with underscore
it wouldn't be confused with bundle members etc
Hopefully, somebody will propose a better version
24 жовтня 2018, 22:21:44, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Wed, 24 Oct 2018, Sven Schreiber wrote:
Am 24.10.2018 um 01:41 schrieb Allin Cottrell:
> That's already answered. It will _not_ cause a problem unless your database
> contains a series named "lagreg", of which you want to take lags using the
> "series_name(<lag-spec>)" syntax.
> That (lag) syntax long predates the possibility of user-defined functions
> in hansl. So far as I know this sort of collision has never been a
> practical problem to date, but it's not very satisfactory that it's
> possible at all.
No complete solution, but one function package depending on another one is
very recent, so I think that situation can be handled relatively easily. What
about the following (partly scoping) rules for the situation where we are
inside a member function of the package and "x(" is ambiguous:
0) If we're talking about a bundle member like "b.x(", then it cannot be a
1) If the function has an x argument of series or list type, assume this is
meant (and lags are wanted). Because everything else would be the author's
fault, as the name of the argument can be easily changed.
2) Next, if the function package has another function "x", take that.
3) If the package depends on another package "p" and wants to use its
function "x", then require a marker in the call, which could be like the
suggested C++ style "p::x", or using a double underscore "p__x"
would prefer over a single underscore here), or perhaps using the
"--frompkg=p" construct that already exists with the open command.
This doesn't solve the problem when we are in the global script scope or in
the console, but then I think an informative warning message might be enough,
something like: "Ambiguous x in line ...., calling the x() function. If you
wanted to take lags of the x series (or list) instead, use the lags()
function to resolve the ambiguity, or delete the x() function if you no
longer need it."
(Alternative: also offer a generic function marker here, like "f__x" which
the parser would resolve to the x function.)
Just some thoughts,
Helpful thoughts. I like the approach of thinking about what ought to
be known by the user/coder at each point, and therefore what might be
an "honestly occurring" ambiguity (versus what could only arise from
I'll think about this some more...
Gretl-devel mailing list