when you do something like this:
foreach someword someseries [
print someword
]
then someword is set to the values
of someseries, but only within the code block
of the foreach loop.
I think there is a new context created for the
foreach invocation, and in that context
the value of someword is indeed repeatedly
set to each element of someseries.
Notice that you won't be able to see
someword outside the foreach loop before
or after it, although you may be able
to see something if someword has
a value in the enclosing, possibly global context.
This is actually a good feature of rebol, I like it.
In other languages like c, pascal, or basic,
you can see the looping variables value after
the function executes, and in large software
you have to worry about clobbering some other
variable. But here you know that whatever
word you choose to use with foreach will only
be redefined within the code block, and not
anywhere else.
Now, doindx1 is defined much earlier,
and it has a code block which when created
will have find initial to be a local variable
of the run function, so that is what is bound
there inside doindx1 when the function
creation is evaluated.
To do what you want, you would have to move
doindx1 down into the foreach loop,
or else pass it as a parameter, or else
don't use foreach, or else use some other
global variable.
-Galt
>===== Original Message From [EMAIL PROTECTED] =====
>The code at the bottom of this email displays either a bug
>in REBOL 2.3.0.4.2 or a bug in my head. The sample was
>quickly cut down from a larger program under development
>to try to demonstrate the key issue, so it's a bit untidy.
>
>The code was supposed to perform a sort of 2-d traversal
>of the alphabet. After a letter is picked for the row,
>pick a letter for the column and, in the original program,
>do something which involves comparing the row and column
>letters.
>
>In the sample output immediately below, it is obvious that
>one method of getting the row letter (using a shared local
>variable) fails miserably, getting stuck on the dummy
>value to which that variable was initialized, and never
>sees any subsequent changes to the variable. The second
>method of getting the row letter (passing it as an argument)
>works, demonstrating that the letter is actually changing.
>
>A : ~ B : ~ C : ~ D : ~ E : ~ F : ~ G : ~
>A : A B : A C : A D : A E : A F : A G : A
>
>A : ~ B : ~ C : ~ D : ~ E : ~ F : ~ G : ~
>A : B B : B C : B D : B E : B F : B G : B
>
>A : ~ B : ~ C : ~ D : ~ E : ~ F : ~ G : ~
>A : C B : C C : C D : C E : C F : C G : C
>
>A : ~ B : ~ C : ~ D : ~ E : ~ F : ~ G : ~
>A : D B : D C : D D : D E : D F : D G : D
>
>A : ~ B : ~ C : ~ D : ~ E : ~ F : ~ G : ~
>A : E B : E C : E D : E E : E F : E G : E
>
>A : ~ B : ~ C : ~ D : ~ E : ~ F : ~ G : ~
>A : F B : F C : F D : F E : F F : F G : F
>
>A : ~ B : ~ C : ~ D : ~ E : ~ F : ~ G : ~
>A : G B : G C : G D : G E : G F : G G : G
>
>So... Why does 'doindx1 fail, while 'doindx2 succeeds?
>Shouldn't changes to the local variable 'initial in
>'run be visible to both of them (albeit by different
>mechanisms)?
>
>-jn-
>
>REBOL []
>
>bug: make object! [
> run: function [
> ][
> initial alphabet letter doindx
> ][
> initial: #"~"
> letter: #"~"
> doindx1: func [] [
> foreach letter alphabet [
> prin [letter ":" initial " "]
> ]
> print " "
> ]
> doindx2: func [initial] [
> foreach letter alphabet [
> prin [letter ":" initial " "]
> ]
> print " "
> ]
> alphabet: "ABCDEFG"
> foreach initial alphabet [
> doindx1
> doindx2 initial
> print " "
> ]
> ]
>]
