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. 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.
Currently you can do this with pointer arguments:
<hansl>
series s1
series s2
series s3
call_to_function(<some-input>, &s1, &s2, &s3)
</hansl>
The problem is that it takes many lines of code if you have several
series you want to get this way. 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.
(I wanted to include an example, but I haven't worked with string arrays
before and cannot find the documentation right now.)
thanks,
sven