Iteratee

The following abstractions are not strictly speaking necessary to work with iteratees, but they do make it more convenient. Enumerators An Enumerator is a convenient abstraction for feeding data into an iteratee from an arbitrary data source. Typically the enumerator will take care of any necessary resource cleanup associated with the data source. Because the enumerator knows exactly when the iteratee has finished reading data, it will do the resource cleanup (such as closing a file) at exactly the right time – neither too early nor too late. However, it can do this without needing to know about, or being co-located to, the implementation of the iteratee – so enumerators and iteratees form an example of separation of concerns. Enumeratees An Enumeratee is a convenient abstraction for transforming the output of either an enumerator or iteratee, and feeding that output to an iteratee. For example, a "map" enumeratee would map a function over each input chunk. ==Motivations==

Iteratees were created due to problems with existing purely functional solutions to the problem of making input/output composable yet correct. Lazy I/O in Haskell allowed pure functions to operate on data on disk as if it were in memory, without explicitly doing I/O at all after opening the file - a kind of memory-mapped file feature - but because it was impossible in general (due to the Halting problem) for the runtime to know whether the file or other resource was still needed, excessive numbers of files could be left open unnecessarily, resulting in file descriptor exhaustion at the operating system level. Traditional C-style I/O, on the other hand, was too low-level and required the developer to be concerned with low-level details such as the current position in the file, which hindered composability. Iteratees and enumerators combine the high-level functional programming benefits of lazy I/O, with the ability to control resources and low-level details where necessary afforded by C-style I/O. ==Examples==

Iteratees are used in the Play framework to push data out to long-running Comet and WebSocket connections to web browsers. Iteratees may also be used to perform incremental parsing (that is, parsing that does not read all the data into memory at once), for example of JSON. Iteratees are a very general abstraction and can be used for arbitrary kinds of sequential information processing (or mixed sequential/random-access processing) - and need not involve any I/O at all. This makes it easy to repurpose an iteratee to work on an in-memory dataset instead of data flowing in from the network. ==History==

In a sense, a distant predecessor of the notion of an enumerator pushing data into a chain of one or more iteratees, was the pipeline concept in operating systems. However, unlike a typical pipeline, iteratees are not separate processes (and hence do not have the overhead of IPC) - or even separate threads, although they can perform work in a similar manner to a chain of worker threads sending messages to each other. This means that iteratees are more lightweight than processes or threads - unlike the situations with separate processes or threads, no extra stacks are needed. Iteratees and enumerators were invented by Oleg Kiselyov for use in Haskell. Later, they were introduced into Scalaz (in version 5.0; enumeratees were absent and were introduced in Scalaz 7) and into Play Framework 2.0. ==Formal semantics==

Iteratees have been formally modelled as free monads, allowing equational laws to be validated, and employed to optimise programs using iteratees. ==Alternatives==

• Iterators may be used instead of iteratees in Scala, but they are imperative, so are not a purely functional solution. • In Haskell, two alternative abstractions known as Conduits and Pipes have been developed. (These Pipes are not operating system level pipes, so like iteratees they do not require the use of system calls). Conduits in particular are associated with substantially richer libraries of primitives and combinators than iteratees; conduit adapters for incremental functionalities such as parsing HTML, XML, generalised parsing, making HTTP requests and processing the responses, exist, making conduits more suitable than iteratees for industrial software development in Haskell, out of the box. • There is also a high-level abstraction named machines. In Scala there is a package called FS2: Functional Streams for Scala, whose ancestry can be traced back to machines via several ports, renames and refactors. • In Haskell, the package safe-lazy-io exists. It provides a simpler solution to some of the same problems, which essentially involves being "strict enough" to pull all data that is required, or might be required, through a pipeline which takes care of cleaning up the resources on completion. ==References==