[Swift-devel] data dependency guts

[Mihael Hategan]

On Wed, 2007-10-10 at 18:54 -0500, Mihael Hategan wrote:
> 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.

Or we could do it implicitly which would reduce the number of changes we
have to do and the amount of troubles. I think it might be a bit too
late for major changes like that.

> 
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel
>