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
<R>
library(pkg1) # equivalent of include a_pkg.gfn
library(pkg2)
<R>
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
pkg2::fun(args)
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
efforts
I do not know what will be easy to realize
Say
pkg._name
Since no names can start with underscore
it wouldn't be confused with bundle members etc
Hopefully, somebody will propose a better version
Oleh
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...
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel@lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel