Thanks for the detailed response below... I must be able to understand how the resources will be used in my system for mission-critical, long-running applications.
Dave On Thu, Feb 4, 2010 at 12:51 PM, John Millikin <[email protected]> wrote: > Both have advantages and disadvantages. The primary advantage of lazy > IO over iteratees is that it's much, *much* easier to understand -- > existing experience with monads can be used immediately. The downsides > of lazy IO, of course, are well documented[1][2][3]. > > Some are fixed by the safe/strict IO packages. However, safe lazy IO > is still "unpredictable" in that it's difficult to know how many > resources will be used, the order of some operations (eg, releasing > handles), or whether some particular expression will throw an > exception. > > Iteratees are useful because the author can make and verify guarantees > about performance (eg, "this code will never read more than 4 KiB at > once"). They also allow pure code to determine the behavior of IO, > safely, which is useful when writing libraries which must deal with > large amounts of data (eg, streaming a file over HTTP). The Hyena web > server is written using iteratees, and from what I've heard the > authors have been quite happy with their properties. > > I've also found iteratees to perform somewhat better than lazy IO, > though I don't know why. > > Downside: iteratees are very hard to understand. I wrote a > decently-sized article about them[4] trying to figure out how to make > them useful, and some comments in one of Oleg's implementations[5] > suggest that the "iteratee" package is subtly wrong. Oleg has written > at least three versions (non-monadic, monadic, monadic CPS) and I've > no idea why or whether their differences are important. Even dons says > he didn't understand them until after writing his own iteratee-based > IO layer[6]. > > tl;dr: Lots of smart people, with a history of being right about this > sort of thing, say iteratees are better. Evidence suggests > iteratee-based IO is faster and more predictable than lazy IO. > Iteratees are really hard to understand. > > [1] http://okmij.org/ftp/Haskell/Iteratee/Lazy-vs-correct.txt > [2] > http://www.kuliniewicz.org/blog/archives/2010/01/27/happstack-and-streaming-part-4-the-flaw/ > [3] http://forums.xkcd.com/viewtopic.php?f=11&t=46780 > [4] http://ianen.org/articles/understanding-iteratees/ > [5] http://okmij.org/ftp/Haskell/Iteratee/IterateeM.hs , search for > "Drawbacks of this encoding" > [6] > http://stackoverflow.com/questions/1319705/introduction-or-simple-examples-for-iteratee > > On Thu, Feb 4, 2010 at 08:29, David Leimbach <[email protected]> wrote: > > Hi everyone, > > This is not an attempt to start a flame war. I'm just trying to get a > good > > feel for the advantages and disadvantages of the newer safe lazy io lib > > available on Hackage vs using Iteratee. > > It does appear to me that using something like Itereatee gives a bit of > room > > to really tweak the low level enumerator/iteratee relationship, and, if > you > > asked my old boss, I'm just a big fan of folds too, I use them a lot in > my > > Erlang :-), so Iteratee really does appeal to me on many levels. > > Yet at the same time, I'm quite enamored with the beauty of "interact" > and > > functions of that sort. I realize mixing the effects of the lazy IO and > > pure code may not be the clearest way to write code for everyone, but > there > > is something about being able to get linewise data as > > interact (unlines . fmap someLineWiseFunction . lines) > > that is just kind of cool. > > Dave > > _______________________________________________ > > Haskell-Cafe mailing list > > [email protected] > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
