I kind of like the term "monadic action" myself. Here's another perspective that may help you out:
I really like the idea of the "programmable semicolon". That is, in your typical programming languages, you're really working in an implicit State monad. All the in-scope state is carried over from line to line, and each line is separated by a semicolon.
In Haskell, we first get rid of this. We don't like the idea of being able to modify state without being explicit about the types. But of course we still allow you to carry state around. You use >>= to bind "lines" together to use the same state. That's when you get to really take things a step further, though: because state isn't the only "side effect" which you can capture and hide away in a >>=. You can do it with IO, non-determinism, potential failure, etc., etc. And that's where monads come in. It's an interface for gluing together actions with "side effects" in a way in which the actual effects are explicit, but hidden away in the class instance.
Hope this helps!
On Wed, Apr 22, 2009 at 5:06 PM, Daniel Carrera
<daniel.carrera@theingots.org> wrote:
Brent Yorgey wrote:
"Computation" does not really have any technical meaning, it's just
supposed to be an intuition. But the term "computation" is often used
to refer to things of type (m a) where m is a Monad. You can clearly
see from the types that something of type (m a) is different than
something of type (a -> b). The former takes no inputs and somehow
produces value(s) of type a; the latter takes something of type a as
input and produces something of type b as output.
However, you could also legitimately thing of things of type (a -> b)
as "computations"; more interestingly, you can think of things of type
(a -> m b) as "parameterized computations" which can be composed in
nice ways.
Don't rely too heavily on the "computation" idea; monads certainly
don't "revolve around computations", it's only one particular way of
giving intuition for monads which does.
It looks to me that one could replace the word "computation" everywhere in the article with "monadic type" (where again, "monadic type" is just an intuition for "m a" where m is a Monad) and the article would be equally correct. Am I right?
The Wikipedia article seems to use "monadic type" for the same things that ertes calls "computation".
I can't decide which term gives better intuition. The term "computation" makes binding more intuitive: The computation (m a) returns a value of type "a" can then be fed into a function of type (a -> m b). On the other hand, "monadic type" is more intuitive when you write "Maybe Int" or "IO String".
Anyways, thanks for the help. I'm (slowly) making progress.
Cheers,
Daniel.