On 2011-03-26, Gregory Collins <g...@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. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
