Re: [Gretl-devel] PROTECT_LIST: first casualties (long)
On Fri, 18 Jul 2008, Riccardo (Jack) Lucchetti wrote:
[long quote needed for context]
Consider the following script:
<script>
set echo off
set messages off
function foo(list X)
printf "\nInside function foo:\n"
loop foreach i X -q
printf "$i\n"
end loop
end function
function bar(list X)
printf "\nInside function bar:\n"
loop foreach i X -q
printf "%s\n", varname(i)
end loop
end function
nulldata 10
x1 = normal()
x2 = normal()
list X = const x1 x2
printf "\nOutside a function:\n"
loop foreach i X -q
printf "$i\n"
end loop
foo(X)
bar(X)
</script>
With current CVS, with PROTECT_LISTS=1, it yields:
<output>
Outside a function:
const
x1
x2
Inside function foo:
const
2
3
Inside function bar:
index
x1
x2
</output>
Looking at the output of "foo", clearly the constant is treated
specially, which should not happen. ...
Agreed. This is now fixed in CVS.
This also affects the output of "bar", in which varname(i)
becomes varname(const)=varname(1)="index"
No. The fact that you get "index" as the output for the first
iteration in the "bar" loop is the result of using "i" rather than
"$i". The output is correct: i always equals 1 on the first
iteration, and variable 1 is called "index".
Even if the above particular asymmetry is removed, another one
becomes evident: foreach loops inside functions behave
differently from those outside...
The way PROTECT_LISTS works at present, the key point is not
whether we're inside a function as such, but whether the list over
which we're looping, using "foreach", has been made available as a
function argument, or is "native" to the current level of function
execution.
I think it's inevitable that there has to be some such difference.
I agree that we need to think some more about what's the least
confusing way of handling the issue.
Allin.