[Swift-devel] Changes to array closing semantics?

[Michael Wilde]

was: Re: Creating 0.94 RC with fixes for STOMP

 
> Now that we're at it, I was working yesterday on "fixing" array
> closing
> issues. In particular cases like
> int[] a;
> scope1 {
> scope2 {
> a[i1] = v1;
> f(a);
> }
> scope3 {
> a[i2] = v2;
> }
> }
> 
> and variations.
> 
> The idea is that:
> - closing does not need to happen in the declaration scope, but can
> happen in the place where a[] is last written to (in the cases where
> "last written to" happens in multiple places, Ben's partial closing
> will
> still apply, but, again, not necessarily in the declaration scope).
> This
> make a lot of cases that would deadlock before work now.
> - the compiler determines either that:
> 1. closing can happen without a deadlock and issues appropriate
> statements to do so
> 2. there is no way to do it without a deadlock, in which case compiler
> issues a clear error message stating so.
> 
> It's not trivial because I need to keep track of both read and write
> access to variables, and also their respective locations within the
> scope tree, as well as how iterations and if conditions may affect
> things. That combined with the general crappiness of the exiting
> compiler code. But with a bit of work, I think it's doable and it will
> go miles towards reducing unexpected and perplexing behavior in
> complex
> scripts.
> 
>... this might be a
> good
> time to finally put this issue to rest.
> 
> As usual there are advantages and disadvantages to including this in
> the
> upcoming release, so...

This is something that we should carefully coordinate between Swift/K and Swift/T.

I dont fully understand this issues and differences, but I think that Swift/T has added some restrictions that make array closing simpler to define and implement.

I would like to see us either agree on carying the new semantics forward into Swift/T, or retrofitting Swift/T semantics to Swift/K, to start easing the eventual transition for users.

Thoughts, all?

- Mike


-- 
Michael Wilde
Computation Institute, University of Chicago
Mathematics and Computer Science Division
Argonne National Laboratory