From: Pinku Surana <suranap@...>
Date: 2008-09-13T00:03:14+09:00
Subject: Re: Local variable in loop affects callcc

On Sep 12, 6:00 am, Pit Capitain <pit.capit...@gmail.com> wrote:

> The only difference is that the result of the fourth invocation (4:2)
> is stored into different locations of the array "a". The outcome
> depends on the time when the array index "i" is evaluated: in the
> "correct" version the index is evaluated *before* calling the
> #interval method and creating the continuations, in the "wrong"
> version the index is evaluated *after* the call. It has nothing to do
> with introducing a local variable, as you can see in the code above,
> where the "correct" version also uses a local variable.

I modified your code to verify that the continuation is jumping back
to the correct place in the stack, but the value of i is not being
saved correctly. Somehow, your "correct" version causes the runtime to
preserve i on the stack. It also works if I convert the FOR loop to an
EACH method. But somehow the FOR loop doesn't save i correctly. I
suspect Jim's post is closer to the truth. I hope someone familiar
with the runtime can explain why local variables are sometimes not
stored correctly. Your "correct" code works, but FOR loops don't.

inside i==0, but i is really 0
inside i==1, but i is really 1
["/1:1", "/2:1"]
inside i==1, but i is really 1
["/1:1", "/2:1/3:2"]
inside i==0, but i is really 1        ### Here's where "i" did not get
restored correctly
inside i==1, but i is really 1
["/1:1", "/2:1/3:2/4:2/5:1"]
inside i==1, but i is really 1
["/1:1", "/2:1/3:2/4:2/5:1/6:2"]



Modified code:
  for i in 0...2
      # This produces the WRONG output
    if (i==0)
      x = interval
      puts "inside i==0, but i is really #{i}"
    else
      x = interval
      puts "inside i==1, but i is really #(i}"
    end
    a[i] << "/#{@seq += 1}:#{x}"

      # This produces the CORRECT output
#    a[i] << ( x = interval
#              "/#{@seq += 1}:#{x}" )
  end