Re: [Gretl-devel] nesting a function call getting a list doesn't work
Am 22.06.2015 um 16:21 schrieb Allin Cottrell:
On Sun, 21 Jun 2015, Sven Schreiber wrote:
> 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.)
Yes, more or less, though I'd say it's either the user's fault (assuming
the function in question is properly documented) or the function
author's fault (otherwise).
agreed
> 2) But a caller who calls the function anonymously somehow cannot be
> expected to act responsibly and thus deserves special care.
No, that's not my view. Take HoltWinters. This function does some
computations, prints out some statistics, and also offers a list return
that wraps a couple of series. Maybe I'd like to see the statistics but
don't care to accept the generated series, so I don't assign the return
value. Before my code modification of February, I'd have got the two
series added to my dataset regardless. Surprise! That's not Ignacio's
fault, as I see it; it was gretl's fault.
Ok, now I think we're getting to the bottom of this, and probably it's a
matter of style and taste:
To me (and I presume to many other gretl users, but I may be wrong), the
stuff that a function returns is the central thing, maybe apart from
those kind of C-style functions where the return value is just an
integer error code, but still. Most gretl functions also work this way.
IMO that means that whenever such a function is called the default
assumption should be that the user wants the returned stuff and thus
gets it. AFAICS this is the way all functions work in gretl, with the
list-returning functions as the only exception (since Feb 2015). For all
other object types, returned stuff that is optional is covered by
pointer arguments, and that's good.
Now you're saying that lists are special because they have side effects
that are potentially unintended, and that's of course true. Then it
boils down to the question: how do we give the user (some) control over
the side effects? Let me summarize the suggestions:
1) Allin (&Jack): make the non-assigned call special, which protects the
dataset in place. Downside: no way to get the returned list in a 100%
riskless way; inconsistent etc etc.
2) Sven (old and not 100% serious): in some way introduce namespaces
that the caller manipulates through her choice of the assigned list
name. Downside: pretty hefty change.
3) Sven (new and maybe more serious): give the user another explicit
choice to discard the returned list, different from suggestion number
(1). For example with a "null" keyword:
list null = contributed_function(...)
(but the actual implementation of the choice can of course be different;
what's important is that an "empty" call without explicit assignment
would still return the list)
Downside: Also not 100% riskless whenever the return list is fetched.
But at least not inconsistent IMHO.
4) Sven (alternative idea): give the caller a way to override the names
of the returned series in a list. Example
# 'mystrings' would be an array of strings
list outlist[mystrings] = contributed_function(...)
Downside: can't see any right now, apart from the work to implement it.
Obviously I prefer numbers (2)-(4) over the current behavior (1), but
it's as always a matter of taste.
need the list wrapper. It therefore seems a legitimate use-case to
call
log() without assignment in the expectation that the series you want
will be added; otherwise
log(List)
Well yeah it's legitimate, still it's inconsistent with (1) above and
thus is some complication layer.
thanks,
sven