Am 23.10.2018 um 16:09 schrieb Allin
Cottrell:
23 жовтня
2018, 14:39:04, від "Sven Schreiber" <svetosch@gmx.net>:
Am 23.10.2018 um 13:31 schrieb oleg_komashko@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 "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?
thanks,
sven