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

[Adam Megacz]

Responding to a very stale thread here...


Scott Turner <2haskell at pkturner.org> writes:
> And indeed, a channel carrying a sum type corresponds much more
> closely to a pair of channels than does a channel carrying pairs."

I certainly agree with the slogan "a stream of pairs is not the same as
a pair of streams".  However I don't think sums are correct either --
if you have backpressure the behavior is very different.

Suppose I have two incoming streams, one of type A and one of type B,
and (for simplicity) the producers providing these streams do not
communicate with each other in any way.  I can decide not to consume any
values of type B until I receive at least one value of type A.

Now replace my pair of streams with a single stream of (Either A B).  In
order to consume a (Left A) I might have to consume a bunch of (Right
B)'s first; the fact that I have consumed them can be detected by the
B-producer and may influence its behavior in a manner I did not intend.
Even if this is acceptable, there's another problem: I need an unbounded
amount of storage for all those B's -- so this solution won't work in
any sort of hardware design or embedded situation.


Paul L <ninegua at gmail.com> writes:
>> Peter Gammie suggested use of Adam Megacz's Generalized Arrows, which
>> would avoid this problem by use of an opaque product type that can
>> only be converted to a pair by an explicit operation (i.e. 'synch :: a
>> (b**c) (b,c)' for opaque product type (**)). I'm still debating
>> whether to take this approach.

Yes, this is one of the situations where you need the "generalized" part
of generalized arrows; see the blurb in the first paragraph on page 6 [1].

If you look at the corresponding multi-level language, the type of
"synch"'s input (pair-of-streams) is additive conjunction [2] and its
output type (stream-of-pairs) is multiplicative conjunction; both of
these are distinct from Fudgets' additive disjunction (stream-of-sums).
Sadly GHC does not support substructural types, so there's little chance
of these sorts of things being supported in the GHC-based flattener.

  - a

[1] http://arxiv.org/abs/1007.2885

[2] http://en.wikipedia.org/wiki/Linear_logic#The_resource_interpretation