[Haskell-cafe] Asynchronous Arrows need Type Specialization - Help!
dmbarbour at gmail.com
Mon Mar 21 06:18:37 CET 2011
I was giving Control.Arrow a try for a reactive programming system.
The arrows are agents that communicate by sending and returning
time-varying state. Different agents may live in different 'vats'
(event-driven threads) to roughly model distributed computing. For the
most part, the state varies asynchronously - i.e. a file updates at a
different rate than the mouse position. Anyhow, I ran into a problem:
The (***) and (&&&) operations, as specified in Control.Arrow, are
inherently synchronization points.
Ideally one could do something like:
(a1 *** a2) >>> first a3
and the output from a1 would be piped directly as input to a3, without
touching a2. However, arrows also allow:
(a1 *** a2) >>> arr f
And, in this case, the current state of a1 and a2 must be combined
into a stream of pairs so that f may be mapped over the stream.
Obtaining both streams at a single place (a single vat) and time is a
synchronizing operation. The synchronization operations are severely
undermining the intended scalability and performance of this agent
Now, I believe I could make it work if I could somehow specialize the
arrow type with aparametric structure...
A (b,b') (c,c') =
A b c =
But I've not been able to make the Haskell type system happy with
this. Type families allow some specialization, but they don't allow
ambiguity or defaults. Given the 'arr' function, I must be able to
instantiate an A involving any type at all. Today I explored an
alternative version of Control.Arrow, using an opaque product type
specialized to the arrow, but I still bumped into the issue of
specializing the arrow type for this. I don't see how GADTs would
I've been stuck on this for a couple weeks now. Ideas would be appreciated.
More information about the Haskell-Cafe