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 oleg_komashko(a)ukr.net:
> 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
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?