[Swift-devel] Re: restart variable scoping.

[Mihael Hategan]

Right. Me and Yong had a long discussion about this two years ago.

You can "label" things based on the thread id, because it reflects
lexical structure. You cannot, however, do this with foreach loops. Data
is not to be tied to threads there but to actual iteration values,
because they can appear on the iteration channel in any order.
Namely, if you have 

for k in [1:2] {
  X[k] = echo(k);
}

for k, v in X {
  Y[k] = X[k];
}

For the first loop it's fairly clear. k=1 - thread 1-1, k=2 - thread
1-2. But on the second loop this is determined by the order in which the
echoes complete. It can very well be that echo(2) completes first, so
you'll have k=1 - thread 2-2, and k=2 - thread 2-1.

That's why we abandoned the idea eventually (though I forgot it when I
first "fixed" the issue). It could be done, using horribly non-portable
knowledge about the implementation, by going through all the karajan
stack frames and knowing that for loops in swift are compiled to put the
iteration variable in "$$". It will, of course, break if k is not
something easily serializable.

The current idea is that of using something that alludes to a RC: mark
files as valid in a transaction log (simply checking for file existence
on the disk may fail to check consistency of such files).


On Thu, 2008-05-22 at 13:09 +0000, Ben Clifford wrote:
> wrt to the on-going activity around bug NNN about restarts...
> 
> if it is desirable to label restarts based on variable name, rather than 
> by the mapped filename, then:
> 
> the naive approach of storing the variable name as restart identifier:
> 
>  * works for global variables
>  * does not work for non-global variables, because the same variable name 
>    can be used in different scopes, and the same code block can be invoked 
>    multiple times (in procedures and in for loops, for example)
> 
> Some kind of scope identifier on the front might help here. In:
> 
>   (file t) p() {
>      file q=foo();
>      t=qux(q);
>   }
> 
>   a=p();    // l1
>   b=p();    // l2
> 
> the variable 'q' is used twice, once in the call at l1, and once in the 
> call at l2.
> 
> So one might use 'l1' and 'l2', the locations in the source file, as scope 
> identifiers, giving restart identifiers of l1.q and l2.q.
> 
> In a foreach loop, such as:
> 
> foreach a,i in array {  // l3
>    out[i] = p(array); // l4
> }
> 
> we might then scope the various instances of q as:
> 
>    l3-iteration1.l4.q
>    l3-iteration2.l4.q
>    l3-iteration3.l4.q
>    [...]
> 
> with scope labelling being hierarchical.
> 
> The scope identifier is:
> 
>   the containing scope identifier
>    +
>   whatever is needed to identify the new child scope within the containing 
>   scope
> 
> So: entering a foreach loop block appends the iteration identifier to the 
> current scope; making a function call appends the function call source 
> location (or equivalent) to the current scope.
> 
> This is mostly based around me thinking about a SwiftScript level of 
> thinking, rather than a Karajan level of thinking - it may be that this 
> is not easy to do at the karajan level (indeed, it may be that this 
> doesn't work at all anyway). But it seemed worth sending anyway.
>