[Haskell-cafe] ANNOUNCE: enumerator 0.4.8
John Millikin
jmillikin at gmail.com
Sat Mar 26 22:26:35 CET 2011
On 2011-03-26, Gregory Collins <greg at gregorycollins.net> wrote:
>> 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.
I agree that it sucks, but it's a tradeoff of the left-fold enumerator
design. Potential solutions are welcome.
> 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?
I don't think this would help. Remember that the iteratee has *no*
control whatsoever over its lifetime. There is no guarantee that a
higher-level enumerator or enumeratee will actually feed it data until
it has enough; the computation can be interrupted at any level.
Looking at the iteratee package's Stream constructor, I think it
doesn't do what you think it does. While it might help with resource
management in a specific case, it won't help if (for example) an
enumeratee above your iteratee decides to yield.
More information about the Haskell-Cafe
mailing list