I kind of like the term &quot;monadic action&quot; myself. Here&#39;s another perspective that may help you out: <div><br></div><div>I really like the idea of the &quot;programmable semicolon&quot;. That is, in your typical programming languages, you&#39;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.</div>
<div><br></div><div>In Haskell, we first get rid of this. We don&#39;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 &gt;&gt;= to bind &quot;lines&quot; together to use the same state. That&#39;s when you get to really take things a step further, though: because state isn&#39;t the only &quot;side effect&quot; which you can capture and hide away in a &gt;&gt;=. You can do it with IO, non-determinism, potential failure, etc., etc. And that&#39;s where monads come in. It&#39;s an interface for gluing together actions with &quot;side effects&quot; in a way in which the actual effects are explicit, but hidden away in the class instance.</div>
<div><br></div><div>Hope this helps!<br><br><div class="gmail_quote">On Wed, Apr 22, 2009 at 5:06 PM, Daniel Carrera <span dir="ltr">&lt;<a href="mailto:daniel.carrera@theingots.org">daniel.carrera@theingots.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Brent Yorgey wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&quot;Computation&quot; does not really have any technical meaning, it&#39;s just<br>
supposed to be an intuition.  But the term &quot;computation&quot; is often used<br>
to refer to things of type (m a) where m is a Monad.  You can clearly<br>
see from the types that something of type (m a) is different than<br>
something of type (a -&gt; b).  The former takes no inputs and somehow<br>
produces value(s) of type a; the latter takes something of type a as<br>
input and produces something of type b as output.<br>
<br>
However, you could also legitimately thing of things of type (a -&gt; b)<br>
as &quot;computations&quot;; more interestingly, you can think of things of type<br>
(a -&gt; m b) as &quot;parameterized computations&quot; which can be composed in<br>
nice ways.<br>
<br>
Don&#39;t rely too heavily on the &quot;computation&quot; idea; monads certainly<br>
don&#39;t &quot;revolve around computations&quot;, it&#39;s only one particular way of<br>
giving intuition for monads which does.<br>
</blockquote>
<br></div>
Thanks. That helps a lot.<br>
<br>
It looks to me that one could replace the word &quot;computation&quot; everywhere in the article with &quot;monadic type&quot; (where again, &quot;monadic type&quot; is just an intuition for &quot;m a&quot; where m is a Monad) and the article would be equally correct. Am I right?<br>

<br>
The Wikipedia article seems to use &quot;monadic type&quot; for the same things that ertes calls &quot;computation&quot;.<br>
<br>
I can&#39;t decide which term gives better intuition. The term &quot;computation&quot; makes binding more intuitive: The computation (m a) returns a value of type &quot;a&quot; can then be fed into a function of type (a -&gt; m b). On the other hand, &quot;monadic type&quot; is more intuitive when you write &quot;Maybe Int&quot; or &quot;IO String&quot;.<br>

<br>
Anyways, thanks for the help. I&#39;m (slowly) making progress.<br>
<br>
Cheers,<br><font color="#888888">
Daniel.</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org" target="_blank">Beginners@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/beginners" target="_blank">http://www.haskell.org/mailman/listinfo/beginners</a><br>
</div></div></blockquote></div><br></div>