Lazy IO
lazy I/O
(As opposed to strict, or eager I/O commonly used in imperative programming languages.) The combination of Haskell's non-strict semantics with I/O for certain programming tasks.
Monadic I/O in Haskell is implemented strictly. But for certain tasks, being strict can be a problem. For example, an external dataset could exceed the available memory of either the Haskell program or the computer that runs it, making it impossible to use strictly as a fully-formed expression in Haskell.
In this situation, a less strict approach to I/O can allow the dataset to be processed by the program in smaller portions, to achieve its designated task:
The current consensus seems to be that lazy I/O, just as laziness in general, enables a lot of useful idioms that require much more careful orchestration in languages without lazy evaluation or lazy I/O. Thus, there is little appetite for changing the lazy behaviour of Haskell's I/O function, and newcomers to the language simply have to learn how to manage files correctly to not get bitten by the quirks of lazy I/O.
- Lazy I/O, Norbert Zeh.
Since 2019, laziness can also be used with I/O in SWI Prolog for streaming data:
[...] we present lazy stream generators as a unified Prolog interface for stateful computations on both finite and infinite sequences of data that are produced incrementally through I/O and/or algorithmically.
We expose stream generators to the application programmer in two ways: 1) through an abstract sequence manipulation API, convenient for defining custom generators, and 2) as idiomatic lazy lists, compatible with many existing list predicates. We define an algebra of stream generator operations that extends Prolog via an embedded language interpreter, provides a compact notation for composing generators and supports moving between the two isomorphic representations.
- Lazy Stream Programming in Prolog, Paul Tarau, Jan Wielemaker and Tom Schrijvers (first page).
That another programming language implementation now also supports the combination of I/O with laziness (even if it is just for lists), despite those quirks, renders dubious all calls for the removal of lazy I/O from Haskell.
- See also