Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>As to why people find them so fascinating, I think because they're such a simple idea. The <a href="http://osdir.com/ml/haskell-cafe@haskell.org/2010-08/msg01290.html">recent discussion</a> on Haskell-cafe about a denotational semantics for iteratees devolved into a consensus that they're so simple they're barely worth describing. The phrase "little more than a glorified left-fold with a pause button" sticks out to me from that thread. People who like Haskell tend to be fond of simple, elegant structures, so the iteratee idea is likely very appealing.</p> <p>For me, the chief benefits of iteratees are</p> <ol> <li>Composability. Not only can iteratees be composed, but enumerators can too. This is very powerful.</li> <li>Safe resource usage. Resources (memory and handles mostly) cannot escape their local scope. Compare to strict I/O, where it's easier to create space leaks by not cleaning up.</li> <li>Efficient. Iteratees can be highly efficient; competitive with or better than both lazy I/O and strict I/O. </li> </ol> <p>I have found that iteratees provide the greatest benefits when working with single logical data that comes from multiple sources. This is when the composability is most helpful, and resource management with strict I/O most annoying (e.g. nested <code>alloca</code>s or <code>bracket</code>s). </p> <p>For an example, in a work-in-progress audio editor, a single logical chunk of sound data is a set of offsets into multiple audio files. I can process that single chunk of sound by doing something like this (from memory, but I think this is right):</p> <pre><code>enumSound :: MonadIO m =&gt; Sound -&gt; Enumerator s m a enumSound snd = foldr (&gt;=&gt;) enumEof . map enumFile $ sndFiles snd </code></pre> <p>This seems clear, concise, and elegant to me, much more so than the equivalent strict I/O. Iteratees are also powerful enough to incorporate any processing I want to do, including writing output, so I find this very nice. If I used lazy I/O I could get something as elegant, but the extra care to make sure resources are consumed and GC'd would outweigh the advantages IMO.</p> <p>I also like that you need to explicitly retain data in iteratees, which avoids the notorious <code>mean xs = sum xs / length xs</code> space leak.</p> <p>Of course, I don't use iteratees for everything. As an alternative I really like the <code>with*</code> idiom, but when you have multiple resources that need to be nested that gets complex very quickly.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload