[Haskell-cafe] ANNOUNCE: enumerator 0.4.8

[Gregory Collins]

On Sat, Mar 26, 2011 at 8:03 PM, John Millikin <jmillikin at gmail.com> wrote:
> On Mar 26, 10:46 am, Michael Snoyman <mich... at snoyman.com> wrote:
>> As far as the left-over data in a yield issue: does that require a
>> breaking API change, or a change to the definition of >>= which would
>> change semantics??
>
> It requires a pretty serious API change, as the definition of
> 'Iteratee' itself is at fault. Unfortunately, Oleg's new definitions
> also have problems (they can yield extra on a continue step), so I'm
> at a bit of a loss as to what to do. Either way, underlying primitives
> allow users to create iteratees with invalid/undefined behavior. Not
> very Haskell-y.

You can also write an iteratee which doesn't move to the "Done" state
when it gets EOF. This is equally "bad", i.e. not actually much of a
problem in practice.

> Since the API is being broken anyway, I'm also going to take the
> opportunity to change the Stream type so it can represent "EOF + some
> data". That should allow lots of interesting behaviors, such as
> arbitrary lookahead.

The thing which I find is missing the most from enumerator as it
stands is not this -- it's the fact that Iteratees sometimes need to
allocate resources which need explicit manual deallocation (i.e.
sockets, file descriptors, mmaps, etc), but because Enumerators are
running the show, there is no "local" way to ensure that the
cleanup/bracket routines get run on error. This hurts composability,
because you are forced to either allocate these resources outside the
body of the enumerator (where you can bracket "run_") or play
finalizer-on-mvar tricks with the garbage collector. This kind of
sucks.

The iteratee package has an error constructor on the Stream type for
this purpose; I think you could do that -- with the downside that you
need to pattern-match against another constructor in mainline code,
hurting performance -- or is there some other reasonable way to deal
with it?

G
-- 
Gregory Collins <greg at gregorycollins.net>