[Swift-devel] data dependency guts

[Mihael Hategan]

On Wed, 2007-10-10 at 22:06 +0000, Ben Clifford wrote:

> There does not seem to be an immediately correct easy solution to this.
> 
> One idea I have toyed with a little is doing more compile-time analysis of 
> dataflow to generalise the 'declaration block -> statement block' 
> serialisation, so that there is more serialised/parallel specification in 
> the kml.
> 
> Another is to put add a new concept of 'not mapped yet' to datasets; and 
> allow the same dataflow-ordered execution model that populates values also 
> be used to populate mapping configuration.

Yep, mappers should, too, be futures.

We can actually rewrite the whole thing in the following way (in a
pseudo-karajan language):

Assume File f <type> = proc("blabla");

f := vdl:new(File)
f.setMapper(future(vdl:newMapper(type, args)))
f.getMapper().setValue(future(proc("blabla")))

What's currently happening is that all these things are created as
futures to begin with and parallel() is used for actually running them
in parallel. This complicates the implementation of all the Swift data
stuff.

I think the above would be more consistent.