[Swift-devel] Functional building blocks as concurrency patterns
Ian Foster
foster at anl.gov
Mon Dec 1 21:31:58 CST 2008
Ben:
I've often wondered about developing a mapper that can deal with
infinite/unbounded streams.
Your note reminds me of how I keep wondering whether we should be
doing one of two things:
a) Adopting/adapting some existing functional scripting system to
leverage their investment in compilers, etc.--an investment that is
for us hard to sustain.
b) Moving away from a language to a library, which will be clunkier
and more error prone, but also avoids us having to maintain compilers,
etc.
Regarding nondeterminism--do we have use cases for this?
Ian.
On Nov 29, 2008, at 4:45 PM, Ben Clifford wrote:
>
> This just appeared on lambda-the-ultimate:
>
> http://lambda-the-ultimate.org/node/3108
>
>> While teaching INGI1131, my concurrent programming course, I have
>> become
>> even more impressed by a concurrent paradigm, namely functional
>> programming extended with threads and ports, which I call multi-agent
>> dataflow programming.
>
> Some ofthe concepts overlap or are closely related to SwiftScript
> and so
> some of the discussion on that post is interesting to skim.
>
> Some differences are that:
>
> * we don't have infinite/unbounded streams of data because of the
> way that
> our mappers work at the moment (though it conceptually fits in with
> SwiftScript); and
>
> * we don't have ports (or some other way of introducing non-
> determininism
> in the language itself) - we do have something similar at the
> execution
> layer, though, in the form of job replication, where we allow two job
> submissions to race to start execution and only keep the one that
> starts
> executing (some day it might be desirable to extend this to the one
> that
> finishes first or some other more complex expression, but I don't
> see need
> at the moment)
>
> --
>
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel
More information about the Swift-devel
mailing list