[Haskell-cafe] Asynchronous Arrows need Type Specialization - Help!

[David Barbour]

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
abstraction.

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
help.

I've been stuck on this for a couple weeks now. Ideas would be appreciated.