[Swift-devel] on the semantics of 'array closing'

[Mihael Hategan]

On Fri, 2007-06-15 at 20:13 +0000, Ben Clifford wrote:

> [...]
> But we also support a different assignment syntax for arrays, that looks 
> like this:
> 
>   a[0] = p()
>   a[1] = q()
>   b = s(a)
> 
> This fails at the moment (specifically, I think the execution engine will 
> hang).

Somewhat. The invocation is ok. What happens is that if you iterate over
a with foreach, two iterations will be started, but foreach will keep
waiting to see if no more items appear in the array. Think of arrays as
streams of (k, v) pairs and a size. If the size is unknown, foreach
cannot stop.

> 
> Why? Because the is no one point at which we assign a value to 'a' - the 
> assignment is split over multiple statements, which can be in various 
> places (and inside loops etc).
> 
> There is nothing in the implementation that detects that a has been 
> assigned its value.
> 
> So there is this notion in the karajan intermediate code of 'closing an 
> array'.  This is an assertion made in the object code that all assignments 
> to pieces of an array have been made - that, in affect, the array has its 
> value.
> 
> The suggested hack/workaround for this is to move the array element 
> assignments into a procedure:
> 
>  (file f[]) z() {
>    f[0] = p();
>    f[1] - q();
>  }
> 
>  a = z()
>  b = s(a)
> 
> This works. (which is sort-of a violation of referential transparency)
> 
> It works because Swift implicitly marks arrays returned from compound 
> procedures as closed (which may or may not be correct).

We defined it as correct. Something created in one scope cannot be
modified in a parent scope.

Mihael

> 
> So in most variable scopes, arrays behave like single-assignment 
> variables, but each array can have one specific scope in which members can 
> be assigned to. In that scope, the array cannot be treated as a whole 
> variable.
> 
> In the z() example above, that special scope is the body of z(). In the 
> previous example, that scope is the global scope, and the program is 
> invalid by the rule above that the array cannot be referred to as a whole 
> in the same place that its members are individually assigned to.
> 
> That's my explanation of what's going on now. I think it matches reality. 
> I don't like that this is reality, but it is what we have.
> 
> Comments appreciated.
>