Re: [Gretl-devel] nesting a function call getting a list doesn't work
Am 20.06.2015 um 09:50 schrieb Riccardo (Jack) Lucchetti:
On Fri, 19 Jun 2015, Allin Cottrell wrote:
> 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.
I don't think this is the heart of the current discussion, because there
is no disagreement with respect to "mean" functions that secretly aim to
overwrite your data.
We agree that in principle there should be encapsulation -- but we also
agree/know that gretl's design purposefully doesn't really do this when
it comes to lists.
My main point (and I will formulate it a little bluntly, to get the
point across): Your "safeguard" does not ensure encapsulation, either.
As we know, the assigned name of the returned list has nothing to do
with the names of the member series. So when a user ignores the
function's documentation, dataloss can occur in any case, with explicit
assignment or without. Therefore the "safeguard" argument is not valid
to justify your change. Instead your Feb 2015 change is an ad-hoc
special-casing that makes it harder to program in hansl.
Things would be somewhat different if you had proposed the following
change: Always prepend names of list members that are returned in a
function with the name of the list. Example:
<hansl_imaginary>
function list f1(void)
series a = 0
series b = 1
list outlist = a b
end function
list mylist = f1(void)
# new series in dataset: mylist_a and mylist_b
</hansl_imaginary>
This would not be 100% clean encapsulation, either, because by
coincidence I could have had a series mylist_a already. But under this
new rule it would be really the caller's fault to use "mylist" for the
list assignment when already there are series names starting with that
string in the dataset. The caller even wouldn't have to read the doc of
the function.
Quite obviously this idea is inspired by namespaces, which "are one
honking great idea -- let's do more of those!"
(https://www.python.org/dev/peps/pep-0020/)
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
As I said above, I think this "explicit assignment" argument is beside
the point, because the individual series within the list are _never_
explicitly assigned under any circumstance, currently.
I'm not opposed to paying a price, but the current state of affairs pays
a price but doesn't really solve the issue.
thanks,
sven