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