Re: [Gretl-devel] nesting a function call getting a list doesn't work (once more)
On Tue, 23 Jun 2015, Sven Schreiber wrote:
Am 23.06.2015 um 16:18 schrieb Ignacio Diaz-Emparanza:
> El 22/06/15 a las 21:47, Sven Schreiber escribió:
>> Am 22.06.2015 um 19:18 schrieb Riccardo (Jack) Lucchetti:
>> ...
>>> # with this, your original y is safe
>>> moo()
>> Safe yes, but of course at the cost of not getting any benefit at all (=
>> the return value) from the function. I call this throwing the baby out
>> with the bathwater. How on earth can this non-retrieval of the return
>> value be considered a solution to the overwriting problem below, if the
>> solution defeats the purpose in the first place???
>
> Yes Sven, but this is the way in which all type of functions work, for
> example,
>
> <hansl>
> function scalar a()
> scalar b=2
> return b
> end function
>
> nulldata 6
> a()
> </hansl>
>
> the a() invocation does not save the result,
You almost had me there Ignacio, but not quite, because after your function
definition this line:
series look = log(a())
of course will work and use the call a() fruitfully. In fact, this anonymous
retrieval of the return value was exactly how this whole discussion started,
because *only* list-returning functions have been the exception (since Feb
2015).
I've been thinking about this some more and my view is getting closer
to Sven's, at least in regard to the use of a call to a list-returning
function in the context of a function-argument slot.
If a call to list-returning function foo() is used in place of a
pre-defined list, in a call to a function that wants a list argument,
I think it's only reasonable to assume that the caller _does_ want the
side-effect of foo (possible addition of series to the dataset), even
if he or she has no non-transient use for the direct return value (as
a named list object).
In CVS I've modified my check: we now bar the side-effect of a
list-returning function only if it is called by itself, without
assignment, as in plain
foo(<args>)
Now, I've mentioned that at present this bar does not apply to
built-in list-returning functions such as log(); they will have their
side-effects regardless. If my feet were held to the fire on the
inconsistency here, I think I'd want to generalize the bar to log()
and co.
Allin