Editing The I/O problem (section)

=== A historical note ===

The stream-based (or dialogue) I/O model provided in Haskell prior to version 1.3 required substantial support from implementations e.g. by using an imperative “wrapper”:

<blockquote>
It repeatedly takes a request off the result list, acts on
the request, and attaches an appropriate response to the argument list. There has be some clever
footwork to deal with the fact that the function has to be applied to a list of responses before
there <i>are</i> any responses in the list, but that isn’t a problem in a lazy setting.

:<small>[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.13.9123&rep=rep1&type=pdf Tackling the Awkward Squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell], Simon Peyton Jones (pages 4-5 of 60).</small><!-- 2001 -->
</blockquote>

So why was it replaced?

<blockquote>
[...] it has several defects:

* It is hard to extend. New input or output facilities can be added only by extending the <code>Request</code> and <code>Response</code> types, and by changing the “wrapper” program. Ordinary users are unlikely to be able to do this.

* There is no very close connection between a request and its corresponding response. It is extremely easy to write a program that gets one or more “out of step”.

* Even if the program remains in step, it is easy to accidentally evaluate the response stream too eagerly, and thereby block emitting a request until the response to that request has arrived – which it won’t.
</blockquote>

The monadic interface helped to shift the first problem - the difficulty of extending - out of those early Haskell implementations:

<blockquote>
* <i>It is easily extensible</i>. The key to our implementation is to extend Haskell with a single form that allows one to call an any procedure written in the programming language C [https://archive.org/details/cprogramminglang00kern <span></span>], without losing referential transparency (Section 2.3). Using it programmers can readily extend the power of the I/O system, by writing Haskell functions which call operating system procedures.

:<small>[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86.9725&rep=rep1&type=pdf Imperative functional programming] Simon Peyton Jones and Philip Wadler (first page).</small><!-- 1993 -->
</blockquote>

This made it possible to define dialogue I/O, “wrapper” and all, in Haskell:

<blockquote>
The entire I/O system provided by our compiler
is written in Haskell, using the non-standard extensions
we describe below. The language’s standard <code>Dialogue</code>
interface for I/O is supported by providing a function to
convert a <code>Dialogue</code> into our <code>IO</code> monad.

:<small>(second page).</small>
</blockquote>

Any proposal which involves shifting I/O <i>back</i> into modern Haskell implementations must therefore have a practical solution to that original problem - the difficulty of extending implementations.