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