Re: [Gretl-devel] nesting a function call getting a list doesn't work
Am 21.06.2015 um 10:53 schrieb Allin Cottrell:
Sven, you're misunderstanding how "returning a list" works in hansl.
No I don't, everything you explain was actually how I already thought
things worked.
series in the input list that are strictly positive. However,
we're
talking here about the (presumably more common) case where a function
returns a list that contains one or more newly created series.
yes
... and the caller assigns the return value.
Part of my point is that there is no "the" (=one and only) return value
when we talk about lists. There is the name of the list and that is
assigned. Then there are names of the list members, and those *cannot*
be assigned (=renamed) under hansl's design.
I feel like I'm repeating "look at the return value of the names of the
list members" and keep getting the reply "check out the return value of
the list name itself", but those are completely independent under
current hansl design.
function offers a list return and it is _not_ assigned by the
caller,
then all series defined within the function are discarded on exit, so
there can be no series-name collision.
I understand that. But there still *can* be series-name collision if the
caller assigns a new list name.
What you're effectively saying is:
1) If the caller assigns a new list name it's all her fault if something
goes wrong. (I'm actually fine with this, though we can --and have--
talked about design changes that would improve the situation.)
2) But a caller who calls the function anonymously somehow cannot be
expected to act responsibly and thus deserves special care.
I fail to see the logic of the combined assumptions behind 1&2.
At present our built-in data-transformation functions are not subject
to
the same constraint. If you do, for example,
<hansl>
list X = <whatever>
log(X)
</hansl>
then despite the non-assignment of the return value of log(), the logs
of the members of X will be added to the dataset. Obviously there's a
case for saying this is inconsistent behavior, but I think it's
defensible. I won't get into that right now;
I agree, this is certainly not the problematic case. IMO it's the
special treatment of non-assigned contributed functions above.
thanks,
sven