Re: [Gretl-devel] nesting a function call getting a list doesn't work
On Fri, 19 Jun 2015, Allin Cottrell wrote:
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?
Well, yes. If you run the code below (slight modification of the
previous version),
<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()
# your precious data
print you_would_think_this_is_safe
# apparently harmless function call
moo()
print you_would_think_this_is_safe
# data are gone!
</hansl>
then here's what you get:
<output>
? print you_would_think_this_is_safe
Full data range: 1 - 10 (n = 10)
2.43453 0.131361 -0.220725 -1.66478 0.692591 0.933474 0.830973
0.407995 -0.102742 -0.500323
# apparently harmless function call
? moo()
? print you_would_think_this_is_safe
Full data range: 1 - 10 (n = 0)
NA NA NA NA NA NA NA NA
NA NA
# data are gone!
</output>
2) If and when a contributed function package returns a list, it
should be
just as explicit as the built-in functions with regard to the character and
naming of the series members of the returned list. Again, there should be no
surprises for anyone who has read the doc. I would regard violation of this
principle as sufficient reason to reject a function package.
This. This is, IMO, the heart of the matter.
In my opinion a hansl function should never produce any changes in
the
caller's data other than via assignment of a return value or modification of
an argument given in pointer form ("commands" are a different matter). It's
a
somewhat unfortunate (but, I think, unavoidable) consequence of this that you
can't call a function to create an on-the-fly, anonymous list to serve as an
argument to another function.
Or to put my previous argument into different words: this is the price
that list-producing function have to pay for having the special privilege
of being able to modify certain objects without an explicit assignment
operation or the usage of a pointerised argument. Caveat emptor.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------