[Haskell-cafe] ANNOUNCE: enumerator 0.4.8

[wren ng thornton]

On 3/27/11 9:58 PM, John Millikin wrote:
> Resending is slightly more complex -- if the other end can say "resend that
> last chunk", then it should be easy enough, but "resend the last 2 bytes of
> that chunk you sent 5 minutes ago" would be much harder. What is your use
> case?

This does highlight one of the restrictions I've lamented about the 
iteratee framework. Namely that the current versions I've seen place 
unnecessary limitations on the communication the iteratee is allowed to 
give to the enumerator/enumeratees above it. This is often conflated 
with the iteratee throwing an error/exception, which is wrong because we 
should distinguish between bad program states and argument passing. 
Moreover the type system doesn't capture the kinds of communication 
iteratees assume of their enumerators/enumeratees, nor the kinds of 
communication supported by the enumerators/enumeratees, which means that 
failure to hook them up in the right (non-typechecked) way /does/ 
constitute an error.

The one example that tends to be supported is the iteratee requesting 
that the enumerator/enumeratees seek to a given position in a file. 
Which is a good example, but it's not the only one. Requesting the 
resending of chunks is another good example. But there's no limit to the 
reasonable kinds of communication an iteratee could want.

In an ideal framework the producers, transformers, and consumers of 
stream data would have a type parameter indicating the up-stream 
communication they support or require (in addition to the type 
parameters for stream type, result type, and side-effect type). That way 
clients can just define an ADT for their communication protocol, and be 
done with it. There may still be issues with the Expression Problem, but 
at least those are pushed out of the stream processing framework itself 
which really shouldn't care about the types of communication used.

-- 
Live well,
~wren