Re: [Gretl-devel] PROTECT_LIST: first casualties (long)
On Sat, 19 Jul 2008, Riccardo (Jack) Lucchetti wrote:
Would I be wrong if I summarised the current state of affairs
(with PROTECT_LISTS=1) as follows?
List is local: $i returns a string and $i_foo is a valid
identifier and
genr $i_foo = normal()
is a valid statement.
List comes "from the outside" as a function argument: $i returns
a number and $i_foo is _not_ a valid identifier. To get the same
effect as above, you need to work with strings, as in
sprintf vnam "%s_foo", varname($i)
genr @vnam = normal()
As of the time of writing, this is quite right! However, in
current CVS I'm experimenting with the alternative whereby you can
refer to list-variables using listname.varname. For example, in
this scheme the cubes function would look like this:
function make_cubes (list xlist)
list retlist = null
loop foreach i xlist
sprintf newname "%14s_3", "$i"
series @newname = xlist.$i^3
setinfo @newname -d "cube of $i"
list retlist += @newname
end loop
return list retlist
end function
That is, "$i" gets a variable-name string as usual, but if you
want to use this to get the values of a listed variable (where the
list has been supplied as an argument) you need the "listname."
prefix.
I'm trying this because I accept your point that it's very
much preferable that "$i" does the same thing in all foreach-loop
contexts if this is at all feasible.
Limited testing suggests that listname.varname works pretty well.
But it has this limitation: it will be unpacked properly only in a
genr-type context. Per contra, if you try, e.g.
loop foreach i xlist
print xlist.$i
end loop
"xlist.<name>" will not be recognized as a valid construction.
Now obviously the above fragment is artificial and redundant,
since you could just do
print xlist
I'm not sure yet how likely it is that a real function would run
into this sort of problem. If it is a real issue, I think the
best solution is to pass all list-construction through genr, which
is something I've had in mind for a while anyway.
Allin.