<br><br><div><span class="gmail_quote">On 8/14/07, <b class="gmail_sendername">Michael Vanier</b> &lt;<a href="mailto:mvanier@cs.caltech.edu">mvanier@cs.caltech.edu</a>&gt; wrote:</span><br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I&#39;m becoming more and more convinced that metaphors for monads do more harm than good.&nbsp;&nbsp;From now on<br>I&#39;m going to describe monads as purely abstract entities that obey certain laws, and that _in<br>certain instances_ can be viewed to be like containers, or actions, or donuts, or whatever.&nbsp;&nbsp;In
<br>other words, a monad is an abstract thing that can generate things that we can metaphorize, but it&#39;s<br>pointless (point-free?) to try to capture the entire concept in a single metaphor.&nbsp;&nbsp;I&#39;m reminded of<br>a physics teacher who was having a similar problem explaining the concept of tensors, until he said
<br>that &quot;a tensor is something that transforms like a tensor does!&quot;.&nbsp;&nbsp;So a monad is something that<br>behaves like a monad does.</blockquote><div><br><br>Nice.&nbsp; As a Haskell beginner (with previous imperative programming experience) I subscribed to this list today to say exactly that.&nbsp; I spent weeks reading different tutorials that attempted to enlighten by means of various abstractions before I finally found one that simply showed the mechanics of the required operators and rules (sounds less formal than laws) that they need to hold to.&nbsp; Even then I hadn&#39;t quite &quot;got it&quot; until I met SPJ at OSCON and heard myself saying, &quot;All monads are are labels in front of values with specific operations defined on them.&quot;&nbsp; His reply was, &quot;Yes!&nbsp; Very abstract isn&#39;t it?&quot;&nbsp; Then I&#39;d &quot;got it&quot;, or realized that I had but hadn&#39;t realized it (if that makes any sense...), as that sequential exchange of ideas (hah!) brought me to the realization that the &quot;abstractions&quot; that monads are held to represent are solely in the usage semantics of aforesaid operations and, while technically the actual labels used don&#39;t matter, we pick labels whose meaning match those semantics.
<br><br>So, yes, don&#39;t start by giving any extra meaning to the basic monad operations than their mechanics.&nbsp; Then show how they can be use to &quot;implement&quot; abstractions like state, uncertainty, etc...<br></div>
<br></div>Oh yeah, start with terms that programmers already know, e.g. encapsulation v. wrappers.&nbsp; Then switch.&nbsp; Don&#39;t start with terminology that&#39;s different and explain the mappings, start with the familiar than follow the mappings to the different.
<br clear="all"><br>-- <br>Erik Jones<br><a href="mailto:mage2k@gmail.com">mage2k@gmail.com</a><br>