On Mon, 2 Feb 2015, Sven Schreiber wrote:
Am 02.02.2015 um 02:15 schrieb Allin Cottrell:
> On Sun, 1 Feb 2015, I wrote:
>
>> As for the crash Thorsten got, that's now fixed in CVS and snapshots:
>> attempting to use "append" within a function will provoke an error (as
>> does "open", which has always generated an error -- but when we banned
>> "open" originally we overlooked the need to ban "append").
>
> Nostra culpa -- or "our bad", if you prefer. I had a feeling there might
> be an example in the Gretl User's Guide where "append" is used inside
a
> function and now I've found it, in the "Gretl and R" section under
> "Technical details".
>
> In that case we just got lucky and there was no crash. I need to think a
> bit more about whether there's a way to support "append" in functions
> without breaking the "encapsulation" we require of functions (basically
> meaning, no unintended side-effects).
I strongly agree that the separation of inner and outer scope of
functions is a good thing. [...]
Ah, it turns out we can maintain that while allowing "append" within
functions (under certain constraints).
The crash that Thorsten got was specific to the case where "append"
inside a function tries to add a series with the same name as a
pre-existing series in the main dataset, not currently visible within
the function. This was actually due to a fairly simple bug, now fixed.
In general "append" can add data either "sideways" (new series) of
"length-wise" (new observations). Within a function we can allow the
former but not the latter. The newly added series will be local to the
function and will disappear when the function exits unless passed back
to the caller via the function's return value.
However, this still leaves the point you go on to raise:
The problem with returning more than a single series from a function
is the issue of moving back and forth the names (identifiers) -- a
general-purpose function cannot know which names in the dataset are
already taken.
Yes, this is awkward; returning a single series is fine but returning
a list can produce name-space collisions.
Somehow it would be nice if one could define a
"placeholder" list to
be passed to a function just as a container with pre-defined names.
Something like:
<hansl-proposed>
list out --varnames="s1 s2 s3"
list out = call_to_function(<some-input>)
</hansl-proposed>
Or a different way: whenever a function returns a list it could be
encouraged (required in the future?) to also accept a string array
argument that contains the names of the list elements.
That's worth thinking about, yes.
Allin