Wolfgang Jeltsch writes:
----- Original Message -----
Am Mittwoch, 21. Dezember 2005 13:15 schrieb Creighton Hogg:
[...]
Monads, I believe, can be just thought of as containers for state.
I would say that you are talking especially about the I/O monad here. A
monad
as such is a rather general concept like a group is in algebra.
While this is correct, I'm afraid that for most of us it is a flavorless
answer. I wish I had the mathematical mind that made the word "group" in
this context instantly intuitively recognizable, but I don't.
I think Phil Wadler said it best when he said that a monad is a
*computation*. If a function is a mapping between input and output values,
a computation is both an invocation of a function and the provision of
values --- which can include state, ordering, and many other things. Of
course, I'm a Phil Wadler fan anyway.
The important point of the integration of imperative programming in
Haskell is
not that it's done using monads. The point is that you have a specific
type
(IO) whose values are descriptions of I/O actions, and some primitive
operations on IO values. The IO type together with two of these primitive
operations forms a monad but this is secondary in my opinion.
Yes and no. It is important for me, at least, to continue to grasp that IO
is just not a functional thing --- it is not captured intuitively in a
function. Rather, it is a computation --- IO doesn't make sense until it
executes in an environment which it can effect. This is why we capture IO
(as well as other computational concepts) in monads, and why (again IMHO)
mondadic IO is so much more effective and intuitive than continuation style
IO or stream based IO ever was.
Dave Barton
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
