Open research problems/The I/O quandary

Some pertinent quotes:

This is hard stuff. Two years ago I spent several hours to write 3 lines invoking IO computations.

Trying to understand the IO (); "belka", Haskell Discourse.

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

Understanding Monads, Nick Hu.

Haskell compromises brilliantly, by fencing off pure and impure functions from one another [...] 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.

A Problem With I/O, Ben Lynn.

Input/output is awkward in declarative languages. 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.

Specifying Input/Output by Enumeration, Walter W. Wilson and Yu Lei.

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.

Of Course ML Has Monads!, Robert Harper.

Functional programmers used to worry about how to solve “the I/O problem”. Functional programming (FP) eschews any notion of side-effect or order of execution, and instead has an order-independent notion of evaluation. In contrast, input & output (I/O) seems to be an inherently effectful, ordered notion.

[...]

In a sense, I see us as in a worse position than before. Since the adoption of monadic IO, it’s been less immediately apparent that we’re still enslaved [...] Our current home is not painful enough to goad us onward, as were continuation-based I/O and stream-based I/O. (See A History of Haskell, section 7.1.) Nor does it fully liberate us.

Can functional programming be liberated from the von Neumann paradigm?, Conal Elliott.

Sadly [...] many Haskell programmers believe that IO is necessary to do "real programming", and they use Haskell as if it were C (relegating lots of work to IO). In other words, monadic IO has proved to be such a comfortable "solution" to I/O in a functional language, that very few folks are still searching for a genuinely (not merely technically) functional solution. Before monadic IO, there was a lot of vibrant and imaginative work on functional I/O. [...]

The C language is purely functional, Conal Elliott.

Stream transformers are fragile to use, continuations are powerful but somewhat clutter the syntax of functions. Monads and uniqueness types both present a trade-off, do we accept the over-sequentialisation imposed by monads, or the visual disorder of explicit environment passing? We believe that a compromise is still to be found [...]

Approaches to Functional I/O, Owen Stephens.

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.

FUNDIO: A Lambda-Calculus With letrec, case, Constructors, and an IO-Interface:, Manfred Schmidt-Schauß.

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.

A Partial Rehabilitation of Side-Effecting I/O:, Manfred Schmidt-Schauß.

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. [...] Yet the understanding of monads is not trivial. The extensive amount of tutorials and questions on the Internet strengthen this thought.

Input/Output in Functional Languages (Using Algebraic Union Types), R.J. Rorije.

The notation for interactive programs written in the monadic style is irritatingly close to the notation used in imperative languages.
[...]
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 after the evaluation of a program [...] but rather in small steps whenever 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 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.

Functions, Frames and Interactions, Claus Reinke.

Although we all love the beautiful aspects of functional languages we must admit that it is difficult to deal with a beast called Input-Output (I/O).

The Beauty and the Beast, Peter Achten and Rinus Plasmeijer.

Open questions:

• Is there an alternate standalone model of I/O with less problems than each of the current models?
• If not, can I/O be moved away from the language (as a model) and into the implementation (making the language denotative), while keeping the resulting language practical to use?
• Or would any denotative language be solipsistic?

Other questions:

• Is the C language "purely functional"?

No:

• C isn't "pure" - it allows unrestricted access to observable effects, including those of I/O.
• C isn't "functional" - it was never intended to be referentially transparent, which severely restricts the ability to use equational reasoning.

• Is the Haskell language "purely functional"?

Haskell is not a purely functional language, but is often described as being referentially transparent.

• Can functional programming be liberated from the von Neumann paradigm?

That remains an open research problem.

• Can a language be "purely functional" or "denotative"?

Conditionally, yes - the condition being the language is restricted in what domains it can be used in:

• If a language is free of observable effects, including those of I/O, then the only other place where those effects can reside is within its implementation.
• There is no bound on the ways in which observable effects can be usefully combined, leading to a similarly-unlimited variety of imperative computations.
• A finite implementation cannot possibly accommodate all of those computations, so a subset of them must be chosen. This restricts the implementation and language to those domains supported by the chosen computations.

• Why do our programs need to read input and write output?

Because programs are usually written for practical purposes, such as implementing domain-specific little languages like Dhall.

Other articles:

• An alternative approach to I/O, Maarten Fokkinga and Jan Kuper.

• Witnessing Side Effects, Tachio Terauchi and Alex Aiken.

• Assignments for Applicative Languages, Vipin Swarup, Uday S. Reddy and Evan Ireland.

• Imperative Functional Programming, Uday S. Reddy.

• Functional Programming with Side Effects, Mark B. Josephs.

• Lambda Calculus For Engineers, Pieter H. Hartel and Willem G. Vree.

• On Zero-Side-Effect Interactive Programming, Actors, and FSMs, Sergey Ignatchenko.

• Unique Identifiers in Pure Functional Languages, Péter Diviánszky.

• Call-by-Need Is Clairvoyant Call-by-Value, Jennifer Hackett and Graham Hutton.

• Nondeterminism with Referential Transparency in Functional Programming Languages, F. Warren Burton.