[Swift-devel] gparallelizer DataflowConcurrency

[Mihael Hategan]

On Sun, 2009-06-21 at 16:28 +0000, Ben Clifford wrote:
> One thing that is apparent here that Swift doesn't have (and I think is 
> better for Swift ot not have) is the distinction between immediate 
> variables (that have a value) and future values (represented by 
> DataFlowVariable objects) - to get access to those future values you need 
> to dereference their value with ~ (which returns the relevant immediate 
> value or if that immediate value is not available, suspends the present 
> thread of execution until such time as that immediate value is available).

This is, from the usability perspective, and advantage. It is a problem
in compiled languages because all variable accesses need to check
whether a variable is a future or not (hence the explicit checks in some
of such languages). A possible optimization is to have futures also be
part of the type system, but it works in a limited number of cases
(unless you generate code for functions for all possible combinations of
futures/non-futures, which can lead to a crazy amount of compiled code,
not to mention you can't do it for collections).

Of course, swift being coarse-grained and all, this doesn't make much
difference.

> 
> The distinction between immediate and future values in the language is a 
> little awkward - for example, instead of z=x+y, you must write z << ~x + 
> ~y to interface the imediate value desiring + operator with the future 
> value variables z, x and y using ~ to dereference and << instead of = to 
> assign.

If you have both futures and non-futures explicitly, you need a way to
distinguish between them at assignment time, whether it's x << 1 or x =
future(1).

>  This exposure of the interfacing between immediate and future 
> worlds seems a bit awkward.
> 
> Swift used to distinguish some between immediate and future values in its 
> implementation (although not really in the syntax); I think its good that 
> we got rid of that distinction and have only future values for everything.
> 
> It would of course be possible to write some kind of + operator that did 
> the referncing and dereferencing, but this would not in general happen 
> automatically for every possible function and operator.

Right. If you want "auto-futures", you need to bind it at a low level in
the language implementation. Also, you don't want to do it for all
functions. Composite functions should not wait for futures:

add(x, y) {
  return x + y;
}

You (probably) only want + to sync on x and y, not add().

> 
> This is the same trouble as using pointers in C with the * operator to 
> access the value of that pointer, or using weak references in Java using 
> .get() syntax to access the value of the weak reference - its nothing 
> particularly specific to programming using futures. But it looks ugly and 
> awkward in all of them...
> 

Again, the problem is that if you want seamless futures, they can't be
added as an afterthought to your language. And if you do have them as
part of your language, you get a performance penalty.

It may be possible, however, to compile Swift to this thing, since I
assume you can use Java libraries in Groovy seamlessly. I'm not sure,
however, of their green thread implementation. I think it's a very
difficult business to make green threads appear preemtible.