Editing The I/O problem (section)

== Other articles ==

* [https://aitopics.org/download/classics:4A93472A LOGLISP: an alternative to PROLOG], John A. Robinson and Ernest E. Sibert. <!-- 1982 -->

* [https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-56.pdf A New Scheme for Writing Functional Operating Systems], William Stoye. <!-- 1984 -->

* [https://core.ac.uk/download/pdf/82162724.pdf Functional Programming with Side Effects], Mark B. Josephs. <!-- 1986 -->

* [https://www.cs.unc.edu/techreports/88-022.pdf The Semantics of an FP Language with Infinite Objects], Teresa Thomas. <!-- 1988 -->

* [https://dl.acm.org/doi/pdf/10.1145/42192.42194 A Mathematical Approach to Nondeterminism in Data Types], Wim H. Hesselink. <!-- 1988 -->

* [https://www.cs.bham.ac.uk/~udr/papers/assign.pdf Assignments for Applicative Languages], Vipin Swarup, Uday S. Reddy and Evan Ireland. <!-- 1991 -->

* [https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50.6183&rep=rep1&type=pdf TIP in Haskell – Another Exercise in Functional Programming], Colin Runciman. <!-- 1991 -->

* [https://vtechworks.lib.vt.edu/server/api/core/bitstreams/17d5c727-8c8b-4433-b7d0-f9f4e1be20e9/content A Functional Approach to Graphics Programming and Modeling], S. Ramakrishnan. <!-- 1992 -->

* [https://www.cs.bham.ac.uk/~udr/papers/imperative-functional.pdf Imperative Functional Programming], Uday S. Reddy. <!-- 1996 -->

* [https://core.ac.uk/download/pdf/81924021.pdf A representable approach to finite nondeterminism], S. O. Anderson and A. J. Power. <!-- 1997 -->

* [https://web.archive.org/web/20151217222912/https://haskell.cs.yale.edu/wp-content/uploads/2011/02/es01.pdf Directions in Functional Programming for Real(-Time) Applications], Walid Taha, Paul Hudak and Zhanyong Wan. <!-- 2001-->

* [https://www.diva-portal.org/smash/get/diva2:1000395/FULLTEXT01.pdf Reactive Objects], Johan Nordlander, Mark P. Jones, Magnus Carlsson, Richard B. Kieburtz, and Andrew Black. <!-- 2002 -->

* [https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.167.3926&rep=rep1&type=pdf Can GUI Programming Be Liberated From The IO Monad], John Peterson, Antony Courtney and Henrik Nilsson. <!-- 2005 -->

* [https://www.f.waseda.jp/terauchi/papers/toplas-witness.pdf Witnessing Side Effects], Tachio Terauchi and Alex Aiken. <!-- 2006 -->

* [https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.95.7225&rep=rep1&type=pdf Programming Languages For Interactive Computing], Roly Perera. <!-- 2007 -->

* [https://web.archive.org/web/20200930035115/https://www.holdermans.nl/pubs/assets/hage08heap.pdf Heap Recycling for Lazy Languages], Jurriaan Hage and Stefan Holdermans. <!-- 2008 -->

* [https://www2.ccs.neu.edu/racket/pubs/icfp09-fffk.pdf A Functional I/O System], Matthias Felleisen, Robert Bruce Findler, Matthew Flatt and Shriram Krishnamurthi. <!-- 2009 -->

* [https://www.sac-home.org/_media/publications:pdf:2012_1.pdf Single Assignment C (SAC): High Productivity Meets High Performance], Clemens Grelck. <!-- 2012 -->

* [https://www.usenix.org/system/files/1311_05-08_mickens.pdf The Night Watch], James Mickens. <!-- 2013 -->

* [https://cs-people.bu.edu/gaboardi/publication/GaboardiEtAlIicfp16.pdf Combining Effects and Coeffects via Grading], Marco Gaboardi, Flavien Breuvart, Shin-ya Katsumata, Dominic Orchard and Tarmo Uustalu. <!-- 2016 -->

* [https://plus.maths.org/content/category/tags/mathematical-mysteries Mathematical mysteries], <i>Plus</i> magazine.

=== More quotes ===
----
<b>1978</b>
<blockquote>
The primary limitation of FP systems is that they are
not history sensitive. Therefore they must be extended
somehow before they can become practically useful.

:<small>[https://www.cs.cmu.edu/~crary/819-f09/Backus78.pdf Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs], John Backus (page 11 of 29).</small><!-- 1978 -->
</blockquote>
----
<b>1980</b>
<blockquote>
An other important point is that FP systems [...] have no means to save
definitions or results produced by a computation and to recall them later. Therefore, they must be imbedded
into an environment capable of performing these tasks for them.

:<small>[https://dl.acm.org/doi/pdf/10.1145/800176.809975 FAD, a Functional Programming Language that Supports Abstract Data Types], Johannes J. Martin (page 2 of 16).</small><!-- 1980 -->
</blockquote>
----
<b>1984</b>
<blockquote>
[...‘stream-processing’ solutions based on] systems of
communicating processes can be described in a purely functional language by recursion over
infinite lists; this is important because it open up the way for problems involving input–output
and communication to be dealt with cleanly within the functional style [[https://eighty-twenty.org/files/Henderson%20-%201982%20-%20Purely%20Functional%20Operating%20Systems.pdf <span></span>]].

:<small>[https://www.researchgate.net/profile/B-Wichmann/publication/243687527_Functional_Programs_as_Executable_Specifications_Discussion/links/5693913908aee91f69a836d7/Functional-Programs-as-Executable-Specifications-Discussion.pdf Functional Programs as Executable Specifications: Discussion], David A. Turner (page 17 of 27).</small><!-- 1984 -->
</blockquote>
----
<b>1986</b>
<blockquote>
Functional languages are extremely powerful and succinct tools for expressing
algorithms[https://www.cambridge.org/9780521245036 <span></span>],
but the way in which the results of such calculations should be
communicated to the outside world is not obvious.

:<small>[https://core.ac.uk/download/pdf/82449736.pdf Message-based functional operating systems], William Stoye (first page).</small><!-- 1986 -->
</blockquote>

<blockquote>
Input and output are perhaps the most systematically
neglected features of programming languages. They are
usually ad hoc, and they are usually poorly integrated
with the other facilities of their hosts – the languages in
which they are embedded.

:<small>[https://dl.acm.org/doi/pdf/10.1145/22627.22382 An Input-Output Model for Interactive Systems], Mary Shaw (first page).</small><!-- 1986 --> 
</blockquote>
----
<b>1987</b>
<blockquote>
The utility of the different programming style imposed by restricting side-effects is debatable, but it
is fair to say that operations such as input and output (since they are history sensitive — i.e. they are
inherently side-effects) are particularly awkward to express.

:<small>[http://aggregate.org/REFINED/thesis.pdf The Refined-Language Approach To Compiling For Parallel Supercomputers], Henry G. Dietz (page 34 of 188).</small><!-- 1987 -->
</blockquote>
----
<b>1989</b>
<blockquote>
Is there any hope of achieving <i>purely functional</i>, yet <i>universal</i>, and of course
<i>efficient</i> I/O?

:<small>[https://web.archive.org/web/20210615132250/https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.49.695&rep=rep1&type=pdf On the Expressiveness of Purely Functional I/O Systems], Paul Hudak and Raman S. Sundaresh (page 2 of 29).</small><!-- 1989 -->
</blockquote>

<blockquote>
It is not clear how one might express an interactive process as a function — this is
still a research topic, see for example [https://www.cs.kent.ac.uk/pubs/1987/142/content.pdf Interactive functional programs: a method and a formal semantics].

:<small>[https://kar.kent.ac.uk/94289/1/257007.pdf The design and implementation of an operating system in a functional language], John R. G. Cupitt (page 10 of 150).</small><!-- 1989 -->
</blockquote>

<blockquote>
Starting with Landin streams many I/O schemes have been proposed for purely functional
languages, but they tend to be <i>ad hoc</i> in the sense of being designed to express
particular kinds of I/O, without aiming for universal power.

:<small>[https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-160.pdf PFL+: a kernel scheme for functional I/O], Andrew Gordon (page 4 of 28).</small><!-- 1989 -->
</blockquote>

<blockquote>
A straightforward
example of such a problematical application is that of a
function which could allow us to interactively query and
modify a database; this is clearly an interactive problem,
since we may only be able to formulate queries once we
have seen the responses to earlier ones.

:<small>[https://academic.oup.com/comjnl/article-pdf/32/2/162/1445725/320162.pdf Functional Programming and Operating Systems], Simon B. Jones and A. F. Sinclair (first page).</small><!-- 1989 -->
</blockquote>

<blockquote>
At present most declarative languages are guest
languages on [...] procedural machines, and able to preserve their
data in the file system provided by the host machine. However, the interface
to the file system that is provided by the guest languages is primitive
and often not referentially transparent.

:<small>[https://www.cs.ox.ac.uk/files/3404/PRG82.pdf A Functional Database], Phil Trinder (page 14 of 210).</small><!-- 1989 -->
</blockquote>
----
<b>1990</b>
<blockquote>
A functional program transforms data into other data according to a certain
algorithm. Functional programs cannot deal with input/output, cannot switch on and
off lamps depending on the value of a certain parameter; in general they cannot deal
with <i>process control</i>.

:<small>[https://repository.ubn.ru.nl/bitstream/handle/2066/17230/13246.pdf Functional Programming and Lambda Calculus], Henk Barendregt (page 324).</small><!-- 1990 -->
</blockquote>

<blockquote>
To maintain correct I/O behaviour the relative temporal ordering of individual I/O operations must be controlled.
[...] However, in pure functional languages, as they are referentially transparent, there is usually no
mechanism to control the temporal ordering of the evaluation, hence maintaining correct I/O behaviour is
non-trivial<sup>3</sup>. [...]

<sup>3</sup>It is non-trival as a programmer needs always to be considering <i>how</i> something will be executed – which
is only possible with a thorough understanding of the evaluation strategy/denotational semantics. It is also a
task from which functional programming is usually claimed to relieve the programmer.

:<small>[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.628.7053&rep=rep1&type=pdf The implementation of practical functional programming languages], Nigel Perry (page 18 of 144).</small><!-- 1990 -->
</blockquote>
----
<b>1991</b>
<blockquote>
Input and output do not require justification: a program without communication with the
outside world is of little use.

:<small>[https://bertrandmeyer.com/ITPL Introduction to the Theory of Programming Languages], Bertrand Meyer (page 214 of 459).</small><!-- 1991 -->
</blockquote>
----
<b>1992</b>
<blockquote>
One consequence of referential transparency is
that it is difficult to incorporate I/O into a pure
functional language. [...] Alternative models have been
proposed which do not suffer from this difficulty; see
for example the Haskell [version 1.1] report[https://www.haskell.org/definition </span></span>],
which attempts to represent the current consensus in the
field. Nonetheless, these other models are notationally
complex, and I/O modeling remains a problem.

:<small>[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.54.8751&rep=rep1&type=pdf Using a Lazy Functional Language for Textual Information Retrieval], Donald Ziff, Keith Waclena, and Stephen Spackman (page 3 of 13).</small><!-- 1992 -->
</blockquote>

<blockquote>
A lot has been said in favour of functional programming
[https://www.cs.cmu.edu/~crary/819-f09/Backus78.pdf <span></span>]
[https://www.cse.chalmers.se/~rjmh/Papers/whyfp.pdf <span></span>]&nbsp;
but the fact is
that functional programming suffers from a paramount lack of appreciation in
the established programming society. For one reason this is caused by the fact
that only recently functional programs have gained execution speeds comparable
to their imperative rivals
[https://repository.ubn.ru.nl/bitstream/handle/2066/107649/1/107649.pdf <span></span>]
[http://www.mbsd.cs.ru.nl/publications/papers/1991/smes91-codegeneration.ps.gz <span></span>]
[https://www.mbsd.cs.ru.nl/publications/papers/1991/groj91-HeapManABCMach.pdf <span></span>].
Another important reason is that functional
programming defected on performing input output (I/O hereafter) with the
outer world.

I/O and functional programming doesn’t seem to be unifiable: functional
languages don’t have the notion of <i>side-effects</i> and lack a precise <i>control of the
evaluation order</i>. These are precisely the important aspects for any I/O model.
There have been many proposals how to deal with I/O (see section 8) but none
of them are completely satisfactory. In particular it is very hard to deal with the
side-effect problem.

:<small>[https://www.mbsd.cs.ru.nl/publications/papers/1992/achp92-HighLevelIO.pdf High Level Specification of I/O in Functional Languages], Peter Achten, John van Groningen, Rinus Plasmeijer (pages 1-2 of 17).</small><!-- 1992 -->
</blockquote>
----
<b>1993</b>
<blockquote>
In the case of input/output, which typically takes the form of an ordered sequence of events, it
has always been hard to deny convincingly that the imperative model is more intuitive. Functional
models using streams or continuations have always been difficult to grasp at first, whereas practically
anyone can quickly come to terms with the ‘input <i>a</i>; print <i>a</i>’ nature of basic (or BASIC) imperative
languages.

:<small>[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.52.2795&rep=rep1&type=pdf Animating Z specifications in Haskell using a monad], Howard S. Goodman (page 25 of 31).</small><!-- 1993 -->
</blockquote>

<blockquote>
A disadvantage of the [stream] method for writing interactive functional
programs is that every part of the output has to be part of the result
of the whole program on the top level. As a consequence it is not a
trivial task to change a program in such a way that for a specific function
that is used somewhere in an expression the value of its arguments
is printed every time the function is called. A change like that, which
can be of interest for tracing or debugging, requires a change of the
structure of the whole program.

:<small>[https://www.researchgate.net/profile/Marko-Eekelen/publication/220688529_Functional_Programming_and_Parallel_Graph_Rewriting/links/00b4952af4a04d487b000000/Functional-Programming-and-Parallel-Graph-Rewriting.pdf Functional Programming and Parallel Graph Rewriting], Rinus Plasmeijer and Marko van Eekelen (page 82 of 623).</small><!-- 1993 -->
</blockquote>
----
<b>1994</b>
<blockquote>
Although the advantages of functional programming are fairly well known, a few areas have
proved troublesome, I/O being one of these.

:<small>[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.38.2254&rep=rep1&type=pdf Functional Languages and Graphical User Interfaces - a review and a case study], Rob Noble and Colin Runciman (page 6 of 51).</small><!-- 1994 -->
</blockquote>

<blockquote>
There are many attempts to integrate I/O into functional languages, such as linear types
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.55.5439&rep=rep1&type=pdf <span></span>], and monads
[https://www.research.ed.ac.uk/files/7944776/Comprehending_monads.pdf <span></span>]
[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.9361&rep=rep1&type=pdf <span></span>]&nbsp;
in Haskell, or uniqueness typing in Clean
[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.43.6060&rep=rep1&type=pdf <span></span>]
[https://www.researchgate.net/profile/Marko-Eekelen/publication/221024513_Guaranteeing_Safe_Destructive_Updates_Through_a_Type_System_with_Uniqueness_Information_for_Graphs/links/00b7d539eeb0638d07000000/Guaranteeing-Safe-Destructive-Updates-Through-a-Type-System-with-Uniqueness-Information-for-Graphs.pdf <span></span>].
These approaches have in common that the programmer explicitly has to create
data dependencies among consecutive I/O operations which lead to very awkward notations.

:<small>[https://www.sac-home.org/_media/publications:pdf:sac-overview-norwich-94.pdf Single Assignment C - Functional Programming Using Imperative Style], Sven-Bodo Scholz (page 2 of 13).</small><!-- 1994 -->
</blockquote>
----
<b>1995</b>
<blockquote>
In pure functional languages, several proposals have been made for clean
I/O models. We mention Landin’s streams[https://dl.acm.org/doi/pdf/10.1145/363744.363749 <span></span>][https://dl.acm.org/doi/pdf/10.1145/363791.363804 <span></span>],
Monads[https://www.cs.cmu.edu/~crary/819-f09/Moggi89.pdf <span></span>][https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86.9725&rep=rep1&type=pdf <span></span>],
and Uniqueness Types[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.36.5737&rep=rep1&type=pdf <span></span>].
Compared to our approach, these models are more deterministic [when less is required],
especially with respect to output. More generally, these models sequentialize
I/O actions by imposing static constraints (usually expressed as types) on the
program.

:<small>[https://www.researchgate.net/profile/Pum-Walters/publication/243782477_A_Model_for_IO_in_Equational_Languages_with_Don't_Care_Nondeterminism/links/59883bbaaca27266ada3f6c3/A-Model-for-I-O-in-Equational-Languages-with-Dont-Care-Nondeterminism.pdf A model for I/O in equational languages with don’t care non-determinism], H. R. Walters and J. F. Th. Kamperman (page 14 of 15).</small><!-- 1995 -->
</blockquote>
<blockquote>
If, however, we wish to classify programs that have potentially
infinite behaviors, such as a program that echoes its input, then a more direct model of
input-output seems necessary.

:<small>[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.44.2950&rep=rep1&type=pdf Untyped Lambda-Calculus with Input-Output], Jerzy Tiuryn and Mitchell Wand (page 2 of 11)</small><!-- 1995 -->
</blockquote>
----
<b>1996</b>
<blockquote>
The programming style in a lazy functional language is heavily influenced by
the supported I/O-mechanism. Modifying the I/O-behaviour or debugging some
lazy functional program that uses I/O is a black art. It is interesting that novices
in lazy functional programming in general expect that there is some direct
(side-effecting) I/O using a function call.

:<small>[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.55.1076&rep=rep1&type=pdf A Partial Rehabilitation of Side-Effecting I/O:], Manfred Schmidt-Schauß (first page).</small><!-- 1996 -->
</blockquote>

<blockquote>
No formal semantics for these I/O primitives
is possible at present, because there is no
complete formal semantics for Haskell itself. We
hope in future that such a semantics will be
developed. One task of such a semantics would
be to show that the <code>IO</code> type does indeed form a
monad in the categorical sense.

:<small>[https://web.archive.org/web/20080325055637/http://www-fp.dcs.st-and.ac.uk/~kh/papers/io-tutorial/section3_7.html#SECTION0007000000000000000 Monadic I/O in Haskell 1.3], Andrew D. Gordon and Kevin Hammond.</small><!-- 1996 -->
</blockquote>

<blockquote>
For other models of computation like functional or logic programming,
the typical approach has been to add extra features implementing I/O. But
these features do not fit in the nice and simple underlying model: in order
to be able to understand or reason about programs involving I/O, the basic
computational model has to be extended in non trivial ways, making it not so
nice and simple anymore [...]

:<small>[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.48.2591&rep=rep1&type=pdf Input/Output for ELAN], Patrick Viry (first page).</small><!-- 1996 -->
</blockquote>
----
<b>1997</b>
<blockquote>
While it is fine that monadic I/O has good theoretical under-pinnings, did anyone
stop to think if it helped in user interface programming? If all that it is is a means <i>somehow</i>
to construct interactive programs, then it succeeds, but that is not enough. A programmer
chooses a language based not on only on ability, but also usability.

:<small>[https://core.ac.uk/download/pdf/293056217.pdf Interacting with Functional Languages], Duncan Sinclair (page 15 of 159).</small><!-- 1997 -->
</blockquote>
----
<b>1998</b>
<blockquote>
Uniqueness typing addresses the more general problem
of statically controlled use of resources in functional programs and, even if
combined with passing unique representations of environment objects as arguments
to these programs, it does not suffice to solve the input/output-problem. The
reason is that the environment is not updated in one conceptual step <i>after</i> the
evaluation of a program has computed a new environment representation but
rather in small steps <i>whenever</i> the environment representation is modified during
program evaluation. The primitive interactions are thus implemented as
side-effecting operations, the use of which is rendered safe in the
uniqueness-typed environment passing framework.

Similarly, monads are used to address the more general problem of computations
(involving state, input/output, backtracking, ...) returning values: they do
not solve any input/output-problems directly but rather provide an elegant and
flexible abstraction of many solutions to related problems [...]. For instance,
no less than three different input/output-schemes are used to solve these
basic problems in [https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86.9725&rep=rep1&type=pdf Imperative functional programming],
the paper which originally proposed ‘a new model, based on monads, for
performing input/output in a non-strict, purely functional language’. [...]

So, both input/output-schemes merely provide frameworks in which side-effecting
operations can safely be used with a guaranteed order of execution and
without affecting the properties of the purely functional parts of the language.

:<small>[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.95.9846&rep=rep1&type=pdf Functions, Frames and Interactions], Claus Reinke (pages 96-97 of 210).</small><!-- 1998 -->
</blockquote>
----
<b>1999</b>
<blockquote>
Since I/O is by nature side effects, Haskell handles it differently. Monadic I/O is used to overcome this problem.

After overcoming Haskell's I/O, there were no more setbacks in writing the program.

:<small>[https://www.mta.ca/~rrosebru/oldcourse/371199/haskell/paper.htm Functional Programming Using Haskell], Wade Estabrooks, Michael Goit and Mark Steeves.</small><!-- 1999 -->
</blockquote>

<blockquote>
Only theorists find it interesting to write programs that don’t require input or produce output.

:<small>[https://archive.org/details/JavaIO-OReilly Java I/O], Elliotte Rusty Harold (page 21 of 479).</small><!-- 1999 -->
</blockquote>

<blockquote>
Ever since McCarthy [http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf <span></span>]&nbsp;
referred to the input/output (I/O) operations <code>READ</code>
and <code>PRINT</code> in LISP 1.5 as "pseudo-functions," I/O effects have been viewed with
suspicion.

:<small>[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.52.6409&rep=rep1&type=pdf Relating Operational and Denotational Semantics for Input/Output Effects], Roy L. Crole and Andrew D. Gordon (page 2 of 38).</small><!-- 1999 -->
</blockquote>

<blockquote>
Something fundamental and innocent looking as simple I/O has been a hard
problem for functional languages. Many models, such lazy streams, continuation
semantics, and systems model
[https://cpsc.yale.edu/sites/default/files/files/tr665.pdf <span></span>]
[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.16.3541&rep=rep1&typpe=pdf <span></span>]
[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.134.5784&rep=rep1&type=pdf <span></span>]&nbsp;
have been proposed to overcome the discrepancy between a referential
transparent language and I/O side effects. Hudak gives examples of the above
I/O styles [https://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.83.6505&rep=rep1&type=pdf <span></span>]&nbsp;
and although imperative syntax is mimicked they look
very un-intuitive and cumbersome to someone used to plain I/O statements.
Recently, a step forward has been made by employing so-called monads for
I/O [https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86.9725&rep=rep1&type=pdf <span></span>]
<!-- Carlsson & Hallgren, 1993-05? -->. This model has also been adopted
for the latest revision for HASKELL [version 98]. It remains a matter of taste whether such a
treatment of I/O state is conceived as natural or unacceptable.

:<small>[https://docs.ahcts.co/how-to-program/fps-sans-escher.pdf A Functional Pattern System for Object-Oriented Design], Thomas Kühne (page 40 of 346).</small><!-- 1999 -->
</blockquote>
----
<b>2001</b>
<blockquote>
Now that we have discussed the monadic approach in some detail, you may well be asking the
following question: once we have added imperative-looking input/output, concurrency, shared
variables, and exceptions, have we not simply re-invented good old procedural programming?
Have we “lost the plot” [...]

:<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 (page 55 of 60).</small><!-- 2001 -->
</blockquote>
----
<b>2002</b>
<blockquote>
In our approach, we would suggest to dismantle the <code>IO</code>
monad into its constituting monads, and combine them with the
coproduct as needed. This has the advantage that the effects of most
monads can be localised, so using e.g. state threads or exceptions
in one part of the program will not make the type of every function
using this part monadic, as is currently the case with the <code>IO</code>
monad.

:<small>[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.128.1864&rep=rep1&type=pdf Composing Monads Using Coproducts], Christoph Lüth and Neil Ghani (page 11 of 12).</small><!-- 2002 -->
</blockquote>
----
<b>2003</b>
<blockquote>
It is possible that a declarative programming style for the IO
part of a program can be integrated into Haskell.

:<small>[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.69.4510&rep=rep1&type=pdf Realising nondeterministic I/O in the Glasgow Haskell Compiler], David Sabel (page 37 of 39).</small><!-- 2003 -->
</blockquote>

<blockquote>
The common method to relieve the programming language designer from the
inherent IO-problems is to shift responsibility to the programmer who has to
sequentialize all IO-requests. This is also true for the monadic approach
implemented in Haskell [version 98] [https://www.haskell.org/onlinereport <span></span>].

:<small>[https://core.ac.uk/download/pdf/14504553.pdf FUNDIO: A Lambda-Calculus With <i>letrec</i>, <i>case</i>, Constructors, and an IO-Interface:], Manfred Schmidt-Schauß (page 3 of 84).</small><!-- 2003 -->
</blockquote>
----
<b>2004</b>
<blockquote>
As for intrinsic advantage, I think Haskell has at least one obvious handicap -- monadic I/O. Every minute I spend trying to understand how to program with it is a minute I am solving a problem I don't care about.

:<small>[http://lambda-the-ultimate.org/node/186#comment-1436 New Paul Graham thing], <q>sean</q>.</small><!-- 2004 -->
</blockquote>
----
<b>2005</b>
<blockquote>
[...] doing IO in Haskell means using a polymorphic type as well as a mathematical theory that is rather obtuse. That's why IO is so far down in this tutorial.

:<small>[https://web.archive.org/web/20160408094723/http://www.kt.rim.or.jp/~kbk/haskell-intro/section3.html#part7 Haskell Tutorial for C Programmers], Eric Etheridge.</small><!-- 2005 -->
</blockquote>

<blockquote>
<tt>HASKELL</tt> uses <i>monads</i> for destructive updates and I/O; they add a
restricted form of stateful computation to a pure language,
retaining referential transparency
[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91.3579&rep=rep1&type=pdf <span></span>].
The disadvantage is that programs become more complicated. Also,
if imperative elements of a given application were not
taken into account during its design but turn out to
be necessary later on, often major parts have to be
redesigned or (at least) reimplemented, especially because
types change significantly. [...]

The <tt>TRUTH</tt> team considers this point as one of the
biggest drawbacks of the purely functional paradigm as
followed by <tt>HASKELL</tt>.

:<small>[https://homepages.inf.ed.ac.uk/perdita/haskml.pdf Functional programming languages for verification tools: A comparison of Standard ML and Haskell], Martin Leucker, Thomas Noll, Perdita Stevens and Michael Weber (pages 12-13 of 22).</small><!-- 2005 -->
</blockquote>
----
<b>2006</b>
<blockquote>
<b>Booch</b>: What would be your advice to somebody that would want to take up the banner of functional
programming? Where would you suggest they begin, and what hard problems would you like them to
pursue?

<b>Backus</b>: Well, trying to functionalize all the input/output stuff.

<b>Booch</b>: Helping it talk to the real world. 

<b>Backus</b>: Yes.

:<small>[https://archive.computerhistory.org/resources/text/Oral_History/Backus_John/Backus_John_1.oral_history.2006.102657970.pdf Oral History of John Backus], Grady Booch (pages 36-37 of 42).</small><!-- 2006 -->
</blockquote>

<blockquote>
A recognised difficulty with using monads to enforce single-threaded
access to the I/O world is that the programmer is forced
to over-sequentialize their I/O code: I/O operations that are
independent and which could be performed in any order still need to
be given an explicit ordering in the program.

:<small>[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86.4188&rep=rep1&type=pdf Modelling Deterministic Concurrent I/O], Malcolm Dowse and Andrew Butterfield (page 2 of 12).</small><!-- 2006 -->
</blockquote>

<blockquote>
Monadic I/O [https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.41.9361&rep=rep1&type=pdf <span></span>],
the standard approach to I/O in pure languages, forces the programmer to explicitly sequence all I/O
actions. This is not abstract at all, and is hardly a better specification of I/O than any C or
Pascal program. This opinion has been echoed by the functional language community.

:<small>[https://www.scss.tcd.ie/publications/tech-reports/reports.06/TCD-CS-2006-19.pdf A Semantic Framework for Deterministic Functional Input/Output], Malcolm Dowse (page 17 of 224).</small><!-- 2006 -->
</blockquote>

<blockquote>
The downside of I/O using monads is the need for a monad that can not be
unwrapped. So, when using monadic I/O there is no way to get rid of the I/O
monad. Furthermore, it is not as intuitive as one would like it to be. A
prerequisite to good software design is a thorough understanding of the structures
and glues of the implementation language. Monads are an interesting addition to
both of these sets, and therefore a design implication is that the designer needs
to be aware of the potential benefits of using monads. Yet the
understanding of monads is not trivial. The extensive amount of tutorials and
questions on the Internet strengthen this thought. Another disadvantage is that
monads tend to be an all-or-nothing solution[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91.3579&rep=rep1&type=pdf </span></span>]. The transition
from no interaction at all to a single form of interaction is not very smooth.
Parts of the program need to be rewritten.

:<small>[https://essay.utwente.nl/57287/1/scriptie_Rorije.pdf Input/Output in Functional Languages (Using Algebraic Union Types)], R.J. Rorije (page 30 of 130).</small><!-- 2006 -->
</blockquote>
----
<b>2007</b>
<blockquote>
The common practice of mixing IO with functionality inhibits composability whether in C or in Haskell.

:<small>[https://conal.net/blog/posts/tangible-functional-programming-a-modern-marriage-of-usability-and-composability Tangible Functional Programming: a modern marriage of usability and composability], Conal Elliott.</small><!-- 2007 -->
</blockquote>

<blockquote>
[...] the next question that always comes up is how to do IO down in an function (in an expression) down a ways in the code. This often involves rewriting those "expressions" into "commands".

:<small>[http://blog.sigfpe.com/2007/11/io-monad-for-people-who-simply-dont.html#6353382341670425040 The IO Monad for People who Simply Don't Care], <q>jefu</q>.</small><!-- 2007 -->
</blockquote>
----
<b>2008</b>
<blockquote>
[...] for a long time [interaction] was seen as one of the major obstacles
for functional programming. The issues are now better understood, and two
workable solutions have emerged (uniqueness typing and monadic I/O).
Nevertheless, the last word on this issue has not yet been said.

:<small>[https://edsko.net/pubs/thesis.pdf Making Uniqueness Typing Less Unique], Edsko de Vries (page 23 of 264).</small><!-- 2008 -->
</blockquote>

<blockquote>
Support for [external] state in Haskell exists in the form of the I/O monad[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.86.9725&rep=rep1&type=pdf <span></span>], but in our opinion the monadic idiom does not scale well to large, complexly stateful programs, and imposes constraints that are unnatural in the eyes of systems programmers.

:<small>[https://web.archive.org/web/20081212233905/http://www.bitc-lang.org/docs/bitc/bitc-origins.html The Origins of the BitC Programming Language], Jonathan Shapiro, Swaroop Sridhar and M. Scott Doerrie.</small><!-- 2008 -->
</blockquote>

<blockquote>
Supporting IO would require us to extend our heap model to
include relevant aspects of the outside system, plus some kind of nondeterminism for
IO actions to take into account that we can never model the world in its entirety.

:<small>[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.176.4954&rep=rep1&type=pdf Imperative Functional Programming with Isabelle/HOL], Lukas Bulwahn, Alexander Krauss, Florian Haftmann, Levent Erkök and John Matthews (page 15 of 16).</small><!-- 2008 -->
</blockquote>
----
<b>2009</b>
<blockquote>
Writing solutions that are both elegant and efficient for applications that perform
substantial I/O or transform graph-structured data is still a challenge.

:<small>[https://www.cs.kent.ac.uk/pubs/2009/2874/content.pdf Functional Programming], Olaf Chitil (page 20 of 23).</small><!-- 2009 -->
</blockquote>

<blockquote>
As Amdahl’s law states
[https://www3.cs.stonybrook.edu/~rezaul/Spring-2012/CSE613/reading/Amdahl-1967.pdf <span></span>],
the overall speedup that can be achieved
is determined not by the parallel parts of a program but by its
sequential segments. This becomes even more true with increasing
numbers of processing units. Therefore, we believe that even partly
lifting the requirement of strictly sequential I/O can be hugely
beneficial.
:<small>[https://www.sac-home.org/_media/publications:pdf:2009_6.pdf Controlling Chaos: On Safe Side-Effects in Data-Parallel Operations], Stephan Herhut, Sven-Bodo Scholz and Clemens Grelck (page 2 of 9).</small><!-- 2009 -->
</blockquote>
----
<b>2010</b>
<blockquote>
Input/output is awkward in declarative languages [https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.13.9123&rep=rep1&type=pdf <span></span>].
Some functional languages like LISP have procedural read and write operations.
Prolog has ugly read and write "predicates" that execute in sequence.
Haskell monads provide pure functional I/O but still involve a sequence of actions.

:<small>[https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.227.6709&rep=rep1&type=pdf Specifying Input/Output by Enumeration], Walter W. Wilson and Yu Lei (first page).</small><!-- 2010 -->
</blockquote>

<blockquote>
[...] where would I read up more on how we'd get rid of the imperative stuff entirely, [going] purely functional, and still have terminal interaction?

:<small>[https://conal.net/blog/posts/the-c-language-is-purely-functional#comment-487 The C language is purely functional], Raoul Duke.</small><!-- 2010 -->
</blockquote>

<blockquote>
Anyone expecting to use Haskell for primarily I/O related stuff is going to die from frustration.

:<small>[https://otherlibrarian.wordpress.com/2010/09/09/part-ii-how-not-to-start-your-haskell-program Part II: How not to Start Your Haskell Program], Ryan Deschamps.</small><!-- 2010 -->
</blockquote>
----
<b>2011</b>
<blockquote>
A potential drawback of monads, is that they force the use of
a single environment, to be passed between all I/O operations
within a program, effectively sequentialising all I/O operations.

:<small>[https://www.owenstephens.co.uk/assets/static/research/masters_report.pdf Approaches to Functional I/O], Owen Stephens (page 5 of 8).</small><!-- 2011 -->
</blockquote>

<blockquote>
Once you’re in the IO monad, you’re stuck there forever, and are reduced to Algol-style imperative programming. You cannot easily convert between functional and monadic style without a radical restructuring of code.

:<small>[https://existentialtype.wordpress.com/2011/05/01/of-course-ml-has-monads Of Course ML Has Monads!], Robert Harper.</small><!-- 2011 -->
</blockquote>

<blockquote>
Functional languages have many advantages—
being mathematical in nature, it is relatively easy to prove correctness of their
programs—so we would like a way to mimic, in a functional manner, non-functional
side-effects such as input/output and mutable state.

:<small>[https://math.uchicago.edu/~may/VIGRE/VIGRE2011/REUPapers/Berger.pdf On Some Aspects of The Theory of Monads], Carsen Berger (page 14 of 16).</small><!-- 2011 -->
</blockquote>

----
<b>2013</b>
<blockquote>
IO in Haskell [is] for me a source of great displeasure and it just defeated every try I have given to learn the language.

:<small>[https://www.haskellforall.com/2013/01/introduction-to-haskell-io.html?showComment=1361296801442#c794624017122358881 Introduction to Haskell <code>IO</code>], Ludovic Kuty.</small><!-- 2013 -->
</blockquote>

<blockquote>
Purity is pretty much
required for lazy languages, but I/O is very clumsy in pure languages so monadic
I/O was invented for Haskell to solve this problem [https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.168.4008&rep=rep1&type=pdf <span></span>].

:<small>[https://ntnuopen.ntnu.no/ntnu-xmlui/bitstream/handle/11250/253137/618488_FULLTEXT01.pdf?sequence=1 Trace-based just-in-time compiler for Haskell with RPython], Even Wiik Thomassen (page 15 of 96).</small><!-- 2013 -->
</blockquote>
----
<b>2014</b>
<blockquote>
Understanding I/O in Haskell, which implies understanding Monads (at least, the <code>IO</code> Monad) is actually one of the major difficulties I’ve came across while learning Haskell [...]

:<small>[https://discuss.codechef.com/t/is-it-possible-to-solve-tsort-with-haskell/4450/2 Is it possible to solve TSORT with Haskell?], Bruno Oliveira.</small><!-- 2014 -->
</blockquote>

<blockquote>
Here you’re equating functional languages with the inability to make use of benign effects, such as instrumentation of code for profiling purposes, which is indeed very clumsy in Haskell (you either have to rewrite your code to be imperative so that it conforms to the <code>IO</code> Monad, or else you have to admit that you really want ML [or perhaps HasFuse[https://www2.ki.informatik.uni-frankfurt.de/research/diamond/hasfuse/index.html <span></span>]]&nbsp; by using <code>unsafePerformIO</code>).

:<small>[https://www.pl-enthusiast.net/2014/09/02/who-teaches-functional-programming/#comment-564 Who teaches functional programming?], Robert Harper.</small><!-- 2014 -->
</blockquote>

<blockquote>
Although the functional programming community has solved many of the difficulties
in implementation and use of functional languages, more research is needed on
several issues of importance to the real world: on facilities for input/output,
nondeterministic, realtime, parallel, and database programming.

:<small>[https://john.cs.olemiss.edu/~hcc/csci555/notes/haskell_notes.pdf Notes on Functional Programming with Haskell], H. Conrad Cunningham (page 21 of 192).</small><!-- 2014 -->
</blockquote>
----
<b>2015</b>
<blockquote>
[...] you shouldn't spend much time writing <code>IO</code> stuff, because it's a bad language embedded in a good one.

:<small>[https://web.archive.org/web/20220309052143/http://comonad.com/reader/2015/on-the-unsafety-of-interleaved-io On the unsafety of interleaved I/O], Dan Doel.</small><!-- 2015 -->
</blockquote>
----
<b>2016</b>
<blockquote>
<code>IO</code> is indeed a monad instance, but not a very nice
one - the compiler treats it specially, and it is not
very nice to reason about it - instead, we shall explore some
monads which do not put into question Haskell’s purity.

:<small>[https://nickhu.co.uk/Monads.pdf Understanding Monads], Nick Hu (first page).</small><!-- 2016 -->
</blockquote>

<blockquote>
As an example, consider some code that needs access to the current time. This is something that would normally require <code>IO</code>, but we likely want to be able to use the value in a pure context without “infecting” the entire program with <code>IO</code> types.

:<small>[https://lexi-lambda.github.io/blog/2016/06/12/four-months-with-haskell Four months with Haskell], Alexis King.</small><!-- 2016 -->
</blockquote>

<blockquote>
The illusion is so good that programmers are fooled into thinking I/O is pure in Haskell. And now that we can write mostly pure code with occasional impure wrappers, researchers have mostly stopped seeking superior alternatives.

:<small>[https://crypto.stanford.edu/~blynn/haskell/io.html A Problem With I/O], Ben Lynn.</small><!-- 2016 -->
</blockquote>
----
<b>2017</b>
<blockquote>
I like the concise way of coding pure functions in Haskell using mathematical ideas like recursion and list comprehensions. However, user interactions are quite painful to implement using the I/O monad.

:<small>[https://www.linkedin.com/pulse/definition-functional-programming-rainer-grimm The Definition of Functional Programming], Dirk Verlinden.</small><!-- 2017 -->
</blockquote>


[[Category:Mathematics]]
[[Category:Research]]