[Haskell-cafe] Monad explanation

[David Leimbach]

2009/2/5 Gregg Reynolds <dev at mobileink.com>

> On Wed, Feb 4, 2009 at 8:18 PM, Richard O'Keefe <ok at cs.otago.ac.nz> wrote:
>
>>
>> On 5 Feb 2009, at 10:20 am, Gregg Reynolds wrote:
>>
>>> That's a fairly common representation, seems to work for lots of people,
>>> but it caused me no end of trouble.  Values are mathematical objects; how, I
>>> asked myself, can they possibly /be/ programs that do IO (or actions, or
>>> computations, or <your metaphor here>)?  It doesn't make sense, says I,
>>>
>>
>> without reference to the rest of your message, of course values can /be/
>> programs.
>
>
> Not "programs", but "programs that do IO".  The point of the idiom is that
> there's an external side effect involved.  What sticks in my craw is that "a
> mathematical value with a non-mathematical side effect" is, well,
> non-mathematical and possibly nonsensical.  I know it works for some (most?)
> people, but for me it lacks Geometry and Theology.
>
> -g
>
>
I think the point of the Monad is that it works as a container of stuff,
that still allows mathematically pure things to happen, while possibly
having some opaque "other stuff" going on.  If you have a monadic add
operation, and a Monad of some kind that "Contains an Integer", you can call
the Monadic add operation on a pair of those monads, and some of the other
monadic gluey-stuff that happens in between can combine the "other stuff" in
specific ways, depending on how the Monad is defined.  If it's  the identity
monad, it might not be that interesting, but if it's a writer monad, it
might log things that are going on.  m 1 + m 2 = m3, but what happened
inside the "m" is entirely up to how that "m" is defined.

Does that make it a little easier to understand?  IO could have happened in
the "m", but there's still a pure peace.... sometimes :-)  (there's nothing
stopping you reading an integer from the keyboard and returning it to
totally break down that analogy I suppose).

At least this is how I like to think of Monads.  If you want more guarantees
about operations, keep them pure, and then you only have to really
scrutinize the monad-using bits to see where your program can get screwy.

I realize that might not make the mathematician in you feel tons better, but
*shrug*.

Dave


>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/cb29ed38/attachment.htm