Re: [Gretl-devel] "shadowing" over-diagnostics

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