Is this a reasonable view of Haskell IO?
When given a program, the Haskell runtime does the following:
main
to get back an "IO computation"This two-stage approach allows main
to remain a pure function.
An IO computation in this case is like a special version of Haskell that has explicit sequencing - or perhaps there is a better way to describe this?
Haskell is a pure language and even the I/O system can't break this purity. Being pure means that the result of any function call is fully determined by its arguments. Procedural entities like rand() or getchar() in C, which return different results on each call, are simply impossible to write in Haskell.
IO is the way how Haskell differentiates between code that is referentially transparent and code that is not. IO a is the type of an IO action that returns an a . You can think of an IO action as a piece of code with some effect on the real world that waits to get executed.
In spite of Haskell being purely functional, IO actions can be said to be impure because their impacts on the outside world are side effects (as opposed to the regular effects that are entirely contained within Haskell).
Functional programming aims to minimize or eliminate side effects. The lack of side effects makes it easier to do formal verification of a program. The functional language Haskell eliminates side effects such as I/O and other stateful computations by replacing them with monadic actions.
Yeah, that's a decent semantic model of how the programs are executed. The implementation doesn't work like that, of course, but you can still use that model to reason about the programs.
But more generally, what IO
does is to allow you to treat imperative programs as pure values. The Monad
operations then allow you to compose imperative programs from smaller imperative programs (or to use the usual term in this context, actions) and pure functions. So the purely functional model, while it cannot execute imperative programs, can still describe them as expressions of type IO a
, and the compiler can translate these descriptions into imperative code.
Or you could say this:
main
.I.e., the "evaluate main
" part of your model is pushed to the compiler, and is not in the runtime as you first describe it.
Your view of IO
is good, but I have a problem with this line
Calls main to get back an "IO computation"
The best way to think about Haskell is that functions dont do anything. Rather, you declaratively describe what values are. A program consists of a description of an IO
value called main
. The only sense to which it "calls main" is that the declaration of main
is reduced to Weak Head Normal Form (or something similar).
IO
is the type of arbitrary side effect-full computations. The pure subset of Haskell is a purely declarative description of values, that happens to allow for undecidable descriptions. Think of Haskell as a mathematical language like set theory. Statements in set theory dont do anything, but they might involve complicated computations like "the smallest set which contains Akerman's_function(30)". They can also contain undecidable statements like "S = the set of all sets that do not contain themselves"
@amindfv is half right: main
is not a "pure function". It is not a function at all. It is a value, defined by a pure reduction, encoding unpure computation.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With