Could anyone give some pointers on why the unpure computations in Haskell are modeled as monads?
I mean monad is just an interface with 4 operations, so what was the reasoning to modeling side-effects in it?
+5
A:
Could anyone give some pointers on why the unpure computations in Haskell are modeled as monads?
Well, because Haskell is pure. You need a mathematical concept to distinguish between unpure computations and pure ones on type-level and to model programm flows in respectively.
This means you'll have to end up with some type IO a that models an unpure computation. Then you need to know ways of combining these computations of which apply in sequence (>>=) and lift a value (return) are the most obvious and basic ones.
With these two, you've already defined a monad (without even thinking of it);)
In addition, monads provide very general and powerful abstractions, so many kinds of control flow can be conveniently generalized in monadic functions like sequence, liftM or special syntax, making unpureness not such a special case.
See monads in functional programming and uniqueness typing (the only alternative I know) for more information.
Dario
2010-03-21 21:18:37
+1
A:
AFAIK, the reason is to be able to include side effects checks in the type system. If you want to know more, listen to those SE-Radio episodes: Episode 108: Simon Peyton Jones on Functional Programming and Haskell Episode 72: Erik Meijer on LINQ
Gabriel Ščerbák
2010-03-21 21:18:56
This is the best explanation I have ever read. Thank you for writing it! Ps. Can you please edit your code examples so that they weren't all on a single line?
bodacydo
2010-03-21 23:01:30
+1: Hell, sooo good answer on rather complex topic.
gorsky
2010-03-22 08:24:47
+1 but I want to note that this specifically covers the IO case. http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html is pretty similar, but generalizes `RealWorld` into... well, you'll see.
ephemient
2010-03-22 16:46:58
Whoah! I need to read this again.
Damian Powell
2010-04-24 10:14:56
+1 for an excellent explanation. One thing: In your first 4-line code block, you write _world world_, which looks like a typo to me. (I suppose it should read _real world_ or _whole world_?)
stakx
2010-06-05 08:43:22
@stakx: Oops, whole world. Fixed.
KennyTM
2010-06-05 08:51:43
Hey guy, thank you. I understood the chapter about the State monad in Real World Haskell now.
FUZxxl
2010-09-15 06:01:15
+5
A:
As I understand it, someone called Eugenio Moggi first noticed that a previously obscure mathematical construct called a "monad" could be used to model side effects in computer languages, and hence specify their semantics using Lambda calculus. When Haskell was being developed there were various ways in which impure computations were modelled (see Simon Peyton Jones' "hair shirt" paper for more details), but when Phil Wadler introduced monads it rapidly became obvious that this was The Answer. And the rest is history.
Paul Johnson
2010-03-22 07:54:22
+1
A:
It's actually quite a clean way to think of I/O in a functional way.
In most programming languages, you do input/output operations. In Haskell, imagine writing code not to do the operations, but to generate a list of the operations that you would like to do.
Monads are just pretty syntax for exactly that.
If you want to know why monads as opposed to something else, I guess the answer is that they're the best functional way to represent I/O that people could think of when they were making Haskell.
Noah Lavine
2010-03-22 14:44:03