Haskell uses the seriously complex machinery of monads to do I/O, supposedly without side effects (I don't accept this). And you end up writing stuff [...] which to me looks like C. There must be a more functional approach.
Monads Schmonads: Functional Input without tears (PyFL), Bill Wadge.
[...] In the pure functional languages, Haskell and Clean, at present the most developed ones, the I/O problem is solved by respectively monads and uniqueness typing. But using these features, in both cases it is still possible to write incomprehensible code when dealing with I/O.
Gems of Corrado Böhm, Henk Barendregt.
Fundamentally, all functional languages are translated to an imperative language, and it leaks.
It leaks when you need to read and write files, when you need to respond to real-time user events, when you write to the screen or interact with the GPU, or when you communicate with an external process or API.
Functional Programming Is a Leaky Abstraction, Owen Merkling.
[...] Essentially, the Haskell type
IO t combines both the features of [Idealised Algol's]
exp. This makes the [Haskell] framework slightly simpler, but it can be cumbersome if imperative computations are performed extensively. [...]
Handout 9: Imperative programs and the Lambda Calculus, Uday Reddy.
[...] 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. [...]
The Definition of Functional Programming, Dirk Verlinden.
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.
IO in Haskell [is] for me a source of great displeasure and it just defeated every try I have given to learn the language.
Introduction to Haskell
IO, Ludovic Kuty.
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.
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.
[...] Support for [external] state in Haskell exists in the form of the I/O monad, 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.
The Origins of the BitC Programming Language, Jonathan Shapiro, Swaroop Sridhar and M. Scott Doerrie.
[...] 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".
The IO Monad for People who Simply Don't Care, "jefu".
Booch: 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?
Backus: Well, trying to functionalize all the input/output stuff.
Booch: Helping it talk to the real world.
Oral History of John Backus, Grady Booch.
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.
Modelling Deterministic Concurrent I/O, Malcolm Dowse and Andrew Butterfield.
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.
[...] 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.
Haskell Tutorial for C Programmers, Eric Etheridge.
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.
How can we integrate interaction into a purely declarative language?
For Turing's machine, a calculation begins with a problem on its tape, and ends with an answer there. For Church's calculus, reduction begins with a lambda term, and ends with its normal form. For Floyd's flowcharts and Hoare's triples, a program begins in a state satisfying a precondition, and ends in a state satisfying a postcondition. How the initial tape or term or state is input, and how the final one is output, are questions neither asked or answered.
How to Declare an Imperative, Philip Wadler.
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 somehow 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.
Interacting with Functional Languages, Duncan Sinclair.
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ß.
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.
One consequence of referential transparency is that it is difficult to incorporate I/O into a pure functional language. At least, the mechanism familiar to imperative programmers, say, a function of no arguments [...] which returns the next data item of a stream, would be impossible, since successive calls [...] ought to return different values. Alternative models have been proposed which do not suffer from this difficulty [...] Nonetheless, these other models are notationally complex, and I/O [modelling] remains a problem.
Using a Lazy Functional Language for Textual Information Retrieval, Donald Ziff, Keith Waclena, and Stephen Spackman.
[...] 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.
Functional Programming and Operating Systems, Simon B. Jones and A. F. Sinclair.
Functional languages are extremely powerful and succinct tools for expressing algorithms, but the way in which the results of such calculations should be communicated to the outside world is not obvious. [...]
Message-based functional operating systems, Willian Stoye.
The I/O problem is mathematical in origin
The various fields of study collectively referred to as mathematics are abstract in one or more ways:
In particular, they abstract away from the presence of an outside environment. For a declarative programming language like Haskell, which is based on one of these individual fields of study - higher-order functions - this raises the question of I/O and its observable effects:
How must interactions between a program and an external environment (consisting of, e.g., input/output-devices, file systems, ...) be described in a programming language that abstracts from the existence of an outside world?
Functions, Frames and Interactions, Claus Reinke (page 10 of 210).
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.
It should then be of little surprise that attempts to find a "mathematical solution" for I/O have been less than successful:
Researchers began to analyze why it is often harder to prove things about programs written in traditional languages than it is to prove theorems about mathematics. Two aspects of traditional languages emerged as sources of trouble because they are very difficult to model in a mathematical system: mutability and sequencing.
The Anatomy of Programming Languages, Alice E. Fischer and Frances S. Grodzinsky (emphasis added).
- What would be ideal is an extension of one or more fields of mathematics which can elegantly describe interactions with external environments - the appropriate denotational semantics can then be used to map it into languages like Haskell.
- Alternately (and less ideally), if it can be proven that one cannot exist (like the solution to the halting problem) then implementors everywhere can just select the most-suitable model of I/O, as they see fit.
An axiomatic approach
The dependently-typed language Agda relies on Haskell for its outside interactions:
4 Compiling Agda programs
This section deals with the topic of getting Agda programs to interact
with the real world. Type checking Agda programs requires evaluating
arbitrary terms, ans as long as all terms are pure and normalizing this is
not a problem, but what happens when we introduce side effects? Clearly,
we don't want side effects to happen at compile time. Another question is
what primitives the language should provide for constructing side effecing
programs. In Agda, these problems are solved by allowing arbitrary
Haskell functions to be imported as axioms. At compile time, these imported
functions have no reduction behaviour, only at run time is the
Haskell function executed.
Dependently Typed Programming in Agda, Ulf Norell and James Chapman (emphasis added).
Haskell's FFI also allows for arbitrary foreign code to be imported, to only be executed at run time:
instance Monad IO where
return = unitIO
(>>=) = bindIO
foreign import ccall "primUnitIO" unitIO :: a -> IO a
foreign import ccall "primBindIO" bindIO :: IO a -> (a -> IO b) -> IO b
However, Haskell 2010 doesn't allow higher-order FFI declarations, or their use of type variables. It is possible to devise simpler interfaces which can then be used to implement monadic I/O, but Haskell 2010 also imposes restrictions on its I/O type:
IO type serves as a tag for operations (actions) that interact with the outside world. The
IO type is abstract: no constructors are visible to the user.
The Haskell 2010 Report (page 95 of 329).
On being denotative
Instead of just being declarative, there have been calls for languages like Haskell to be denotative:
My vision of “solving the I/O problem” for functional programming is nothing like Haskell’s semantically imperative (non-)solution (called
IO in Haskell), but rather to continue shifting semantically imperative mechanisms out of the programming model and into the implementation of (semantically simple) function application.
because of how various other effects have already been moved out of languages and into their implementations:
[...] Underneath the implementation of our current functional abstractions (numbers, strings, trees, functions, etc), there are imperative mechanisms, such as memory allocation & deallocation, stack frame modification, and thunk overwriting (to implement laziness). [...]
Stack and register munging and jump/
GOTO are implementations of the semantically simpler notion of function application. (I mean “function” in the sense of math and of pure functional programming.) Moreover, stack & register munging is the input/output (IO) part of the implementation of function application. Information goes out of one context and into another.
There is an assumption here:
- I/O is just another "imperative mechanism", no different from the rest, therefore it can be similarly sequestered (after all, they do ultimately rely on the same fetch and store operations provided by the solid-state Turing machine running the program).
...which is false:
- unlike those other memory-based mechanisms, the simplest of I/O is device-based and the exceedingly-vast majority of I/O devices do not behave like memory.
But the historical precedent is compelling, and I/O may yet be confined to the implementation - it just requires a technique different to the ones used to relocate those other mechanisms:
[...] we will someday really learn to look at whole systems in a consistently functional/denotational style (simple & precise semantics). [...]
As for the existence of such a technique:
[...] I don’t care whether you’re playing “Yes, we can” or “No, we can’t”, so long as you’re rigorous. Rigorous proofs of possibility are usually (not always) constructive: demonstrate an example. That demonstration is what I’m working toward and inviting others along, as in this post and most of my other work.
Presumably the efforts to find that "rigorous proof" (for or against) are ongoing. Until then, the most prudent option is to use the model of I/O which is the least disruptive for languages like Haskell, and not just syntactically or semantically:
Unfortunately, a monadic programming style typically differs fundamentally from an ordinary functional style. While this is not as much of a problem if the programming task at hand is side-effecting by nature, it becomes an issue when side effects are only involved peripherally: then, a programmer will be keen to maintain a functional look and feel to the program and not have encapsulation of side effects dominate the overall style of the program.
Heap Recycling for Lazy Languages, Jurriaan Hage and Stefan Holdermans.
Using more than one language
One suggestion is to ease the relocation of effects into the implementation by using a suitable imperative language:
My view is that the next logical step for programming is to split into two non-overlapping programming domains:
- runtime building for ...
- ... mathematical programming languages
[...] Haskell is one example of a programming language where the code aspires to resemble pure mathematical expressions and definitions.
So instead of having the denotative/imperative division within Haskell by way of types, it would be at the language level in the forms of differing syntax and semantics, foreign calls, and so forth. This too could be alleviated by keeping both languages as similar as possible, but if this is taken to its logical conclusion then the only difference between the denotative and implementation languages would be just the imperative features, which would make having two such similar languages effectively redundant:
[...] It merely delays the issue of how one is to communicate with a persistent outside world. Sooner or later the question of interfacing to [networks], remote filing systems and other computers must be faced.
A New Scheme for Writing Functional Operating Systems, William Stoye (page 18 of 31).
[...] Proving correctness is a formal activity. Therefore we must be able to lift an arbitrary implementation to the formal level. In order not to be forced to specify all details of an implementation, we have to admit nondeterminism on the formal level. It is especially useful in treating things like memory allocation, overflow conditions, and uninitialized fields of structured values [as well as concurrency].
The leading principle is to avoid premature or unnecessary design decisions. Therefore we have a preference for loose specifications, which admit a variety of nonisomorphic models. [...]
A Mathematical Approach to Nondeterminism in Data Types, Wim H. Hesselink.
- 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 (thus making the language denotative), while keeping the resulting language relatively practical to use?
- Is the C language "purely functional"?
- 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?
- Only if no-one proves it to be impossible (e.g. like trying to solve the halting problem).
- 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.
- Reactive Objects, Johan Nordlander, Mark P. Jones, Magnus Carlsson, Richard B. Kieburtz, and Andrew Black.