Lazy IO

From HaskellWiki

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.

Lazy I/O explained

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.

Lazy I/O elsewhere

Despite those quirks, it's been possible to use laziness with I/O in SWI Prolog for streaming data since 2019:

[...] 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).

Therefore all calls for the outright removal of lazy I/O from Haskell should be examined in this context.

See also