[Haskell-cafe] ANNOUNCE: enumerator 0.4.8
wren ng thornton
wren at freegeek.org
Mon Mar 28 06:54:37 CEST 2011
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
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.
More information about the Haskell-Cafe