On Fri, 19 Jun 2015, Riccardo (Jack) Lucchetti wrote:
On Fri, 19 Jun 2015, Allin Cottrell wrote:
> I don't see any easy way around this, but I'm open to suggestions.
I don't have a solution, but I'd like to contribute to the discussion with a
reflection. Everybody loves lists. They're so convenient. However, they have
this feudal privilege (that no other gretl citizen has) of being somewhat
exempt from the principle of strict localisation. This can be VERY
troublesom, at times. Consider this, for example.
<hansl>
function list moo(void)
series you_would_think_this_is_safe = NA
list ret = you_would_think_this_is_safe
return ret
end function
# --- main -----------------------------
nulldata 10
# your precious data
you_would_think_this_is_safe = normal()
# apparently harmless function call
moo()
print you_would_think_this_is_safe
# data are gone!
</hansl>
I don't know about you, but I find this slightly disturbing.
But the data are _not_ gone, or not after the change I made in
February of this year. If you don't assign the return value of moo(),
nothing changes in the caller's dataset. Or are you seeing something
different?
There are some built-in gretl functions that return lists. These have
the potential of overwriting data series previously created by the
user, but (I think) they are quite explicit regarding the names of the
series they create and return. Caveat emptor. I wouldn't necessarily
trust a contributed function that returned a list unless I knew the
author well.
IMO that's not a reason to stop using lists. But I think it _is_ a
reason to resist Sven's suggestion that the error resulting from
giving an anonymous, on-the-fly, function-returned list as a function
argument is a gretl bug. I thought it was a bug, at face value, but
now I don't think so; I believe it's a defensible safeguard. However,
the resulting error message should be clearer.
Allin