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"
is possible

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" <>:

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 
> function.
> 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" (which I 
> 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,
> Sven

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 
willful perversity)!

I'll think about this some more...

Gretl-devel mailing list