Responding to a very stale thread here...
Scott Turner <2hask...@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 <nine...@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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
