Why use monads

[jim]

Just posted a short piece on why monads are useful. This was prompted
by some conversations last week with some folks. Comments, questions
and criticisms welcome.

http://intensivesystems.net/tutorials/why_monads.html

Jim

[Chouser]

Thanks for writing that up. I keep reading approachable tidbits
about monads like this, without really digging into learning all
there is to know about monads. It's hardly fair of me to comment
on this at all before I do that deeper digging, but for what it's
worth here's a non-monadic solution to the particular problem
presented. It's just a high-level function that defines
a comp-like fn with the desired behavior:

(defn maybe-comp [& fns]
(fn [x] (reduce #(when %1 (%2 %1)) x (reverse fns))))

Use it like this:

(def all (maybe-comp dec-m double-m inc-m))

It's interesting to me that the definition of maybe-comp above is
arguably simpler that the definition of maybe-m, even without
counting the machinery of 'defmonad'. Presumably this is a hint
to how much more powerful maybe-m is than maybe-comp, and simply
shows I don't yet understand the power of monads.

--Chouser
--
-- I funded Clojure 2010, did you? http://clojure.org/funding

[jim]

Chouser,

You're right that maybe-comp is simpler. Once you realize that the
functions you want to compose are monadic functions under the maybe-m
monad, you get that composition for 'free', with no further mental
effort. With such a simple example, it's hard to see the benefit, but
with more complicated monads the difference between the monad
composition and ad-hoc style becomes greater. Where the ad-hoc version
would have to be debugged, the monad version would already be proven
to be correct.

Beyond that, there are other things that you get 'for free' by using
the monad functions. Don't have time to enumerate them now but might
later.

Jim

[ataggart]

I'd appreciate any added detail, since I had a similar reaction to
Chouser, thus wasn't really grokking the monad (wikipedia's
description is no more helpful).

[Sean Devlin]

+1 ataggart, Chouser

[jim]

I'll see what I can do.

On Dec 23, 2:18 pm, Sean Devlin <francoisdev...@gmail.com> wrote:
> +1 ataggart, Chouser
>

[jim]

I've expanded the tutorial a little. You can skip to "Another example"
for the new stuff. I go through the same exercise using the
probability monad.

http://intensivesystems.net/tutorials/why_monads.html

There are some corresponding additions to the sample code as well.

Jim

On Dec 23, 2:18 pm, Sean Devlin <francoisdev...@gmail.com> wrote:

[Konrad Hinsen]

On 22.12.2009, at 22:14, Chouser wrote:

> It's interesting to me that the definition of maybe-comp above is
> arguably simpler that the definition of maybe-m, even without
> counting the machinery of 'defmonad'. Presumably this is a hint
> to how much more powerful maybe-m is than maybe-comp, and simply
> shows I don't yet understand the power of monads.

If the only monad you are ever going to use is maybe-m, then indeed
you are better off with your specialized maybe-comp function. But you
can make the same point about any abstraction; they never pay off for
a single application. What you gain with monads compared to maybe-comp
and similar special cases is generality: you can apply the monad
approach to function composition to many different situations and
don't have to start from scratch each time.

Konrad.

[Sergey Didenko]

Not on the topic, but quite important - that yellow column on the left is a usability killer, it makes text hard to read. 

I had to manually change it in Firebug just to read the article.

[Vagif Verdi]

On Dec 22, 2:10 pm, jim <jim.d...@gmail.com> wrote:

> Chouser,
>
> You're right that maybe-comp is simpler. Once you realize that the
> functions you want to compose are monadic functions under the maybe-m
> monad, you get that composition for 'free', with no further mental
> effort.

Except different types of monads do not compose, so you have to create
another artificial structure called monad transformers. And these new
structures introduce so much new artificial complexity that any
possible simplification becomes a moot point.

This fact is realized even in haskell community:
http://lambda-the-ultimate.org/node/2749#comment-41078

I'd say that monads add way too much complexity in most cases.
Especially in impure languages where you can do many things much
simpler than involving monads.

[Konrad Hinsen]

On 27.12.2009, at 23:03, Vagif Verdi wrote:

> Except different types of monads do not compose, so you have to create
> another artificial structure called monad transformers. And these new
> structures introduce so much new artificial complexity that any
> possible simplification becomes a moot point.

Please don't confuse the composition of computational steps in a monad
with the composition of several monadic effects into a single combined
monad. The first is quite well understood and I have yet to see anyone
who has used monads in real life claim that they are not useful. The
second aspect is more difficult and less well understood. The current
most popular approach, monad transformers, may turn out to be
insufficient or too complicated, and it may or may not be replaced by
something else. Time will tell. The important point is that that
utility of monads does not depend on monad transformers.

> This fact is realized even in haskell community:
> http://lambda-the-ultimate.org/node/2749#comment-41078

That article is about monad transformers, not monads themselves. BTW,
monad transformers are simpler in Clojure than they are in Haskell
(they are ordinary functions), so some arguments in that thread don't
apply to the same degree.

Konrad.

[David Brown]

On Mon, Dec 28, 2009 at 12:44:31PM +0100, Konrad Hinsen wrote:

>> This fact is realized even in haskell community:
>> http://lambda-the-ultimate.org/node/2749#comment-41078
>
>That article is about monad transformers, not monads themselves. BTW,
>monad transformers are simpler in Clojure than they are in Haskell
>(they are ordinary functions), so some arguments in that thread don't
>apply to the same degree.

Well, they still end up mostly as just functions in Haskell, with lots
of extra wrapping and unwrapping to get the type system to work.

The advantage in Haskell, is that 'lift' and friends (liftIO) figure
out at compile time how many invocations are needed to get to the
right monad.

My biggest complaint about the monad transformers was that they make
the program design fragile. Having to make small changes to what
monads were used tended to have a pervasive effect on the rest of the
code. Much of this had to do with type declarations, so this might
not be as much of an issue with Clojure.

David

[jim]

Don't really understand what point you're making. The way I see it,
monads are incredibly useful for combining functions that all have the
same signature. When you realize that that's the domain you're working
in, you can use a monad and raise the level of abstraction that you're
working at. In this area, the task seems to be educating programmers
about how to use monads effectively. Lot of work yet to do, yet the
theoretical foundation seems to be solid.

Composing monads is a totally different subject with a lot of
theoretical work yet to be done. Presently, monad transformers seem to
be the way forward, but that's open to debate as you've pointed out.