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
