Am 23.10.2018 um 16:09 schrieb Allin Cottrell:
23 жовтня 2018, 14:39:04, від "Sven Schreiber" <>:

Am 23.10.2018 um 13:31 schrieb

Dear all,
If we create a function having a name coinsiding
with the name of a local variable in a package,
Right (confirmed), this shouldn't happen.

Mostly, defining a variable with the same name as a "visible" function won't cause trouble, since the identifier will be handled differently depending on whether it's immediately followed by left parenthesis. But that can mess up with lags:

OK, I see the issue is more complex.

series den = normal()   # warning but no error

Why actually have a warning here? I kind of understand the motivation, but either it's OK to have an identifier and a function of the same name, or it isn't.

series denlag = den(-1) # fails

I guess the problem is that this lag syntax comes from Eviews (or before that, TSP), but Eviews AFAIK requires special naming for functions that resolves this ambiguity, while gretl/hansl doesn't.

In any case I think it's clear that the desired behavior is that the success of doing some internal stuff in a package shouldn't depend on arbitrary functions that are loaded in the current session.

One possible thought is that function-package code shouldn't "see" user-defined functions outside of its own space. But that's probably too restrictive: what about package dependencies, and packaged functions that take a user-function as a "callback" argument?

Yes, I think so, too.

What about banning the special lag-syntax from function packages? I mean there's always lags(1, den) instead.
It's not optimal (not nice), but what else?

Is there any other incarnation of the problem apart from this lags thing?