Re: [Gretl-devel] members of lists returned from functions
On Mon, 11 Feb 2008, Riccardo (Jack) Lucchetti wrote:
On Mon, 11 Feb 2008, Allin Cottrell wrote:
> For now I have it that list-returning user functions just
> overwrite, but perhaps we need to discuss this some more.
I'm personally in favour of the overwrite policy. The logs
command generates variables with the prefix "l_" plus the
original name. This is consistent, logical and predictable.
Imagine this scenario: you have a huge dataset with hundreds of
variables, you take logs _en masse_ via the nice and convenient
"logs" command, only to find, dozens of lines later, that what
you thought was under the name "l_varname34" doesn't contain
what you want, because it's under "l_varname34a". Very
irritating, and hellish to debug. The only good thing that may
come out of this situation is the invention, if you're creative,
of swearwords previously unknown to man.
Yes, that's the viewing I'm coming round to ;-).
There's still an issue to worry about with long variable names.
Obviously we want to ensure that, e.g.,
logs xlist
returns uniquely named variables. And that's not too hard (though
making the unique names "nice" in all cases is another matter).
We can overwrite any pre-existing variables, but mangle to avoid
naming conflicts among the variables that are *generated by this
particular command*.
But what about successive invocations:
logs xlist
logs zlist
where xlist and zlist contain long names that will yield
"cross-conflicting" log names, so to speak? Under the new
proposal as it stands, some of the logs created by the first
command would be overwritten (I think).
But maybe worrying about this falls into the category of trying a
little too hard to stop users from shooting themselves in the
foot.
We can ensure the docs are clear on this point, and leave it up to
the user to use variable names of a sane length. Maybe also print
a message when an existing variable is redefined via an
auto-naming command/function.
Allin.