In Clojure, when should we use a monad instead of a macro and vice-versa?

Question

There are too many tutorials out there on monads that say... "Look! here is a case where we can use a monad" or "This is what a monad is for". What I want to know is what are some of the steps that people use to come to the conclusion that they can say to themselves - "Gee Whiz! It looks like we can use a monad here!"

So when someone tells me... "(blah) has nothing to do with a monad...", it really doesn't help me answer my questions, which are:

• How do I go about determining what sort of patterns in programs could be expressed using monads?
• How can I write my own customised monad when I have identified the potential to use them?

I started a really long question here about monads if anybody is interested to help - Map and Reduce Monad for Clojure... What about a Juxt Monad?.

Back to this Question:

When should we use a monad instead of a macro and vice-versa?

• I've read articles and watched presentations that say... 'Monads are used for DSL abstraction' .... but most of the Clojure DSL libraries (eg. hiccup and korma) are using defmacro and it works great.

And why do we need monads in Clojure if we have macros?

Answer 1

I've been using Clojure for two years now and the only time I ever used monads was as an exercise to show that it could be done. I've never needed them for "real" code.

Monads are much more common in Haskell because:

• They are the idiomatic way of handling stateful computations. In Clojure, you typically handle state with managed references, so monads aren't needed nearly as much in Clojure.
• Likewise for IO: Clojure allows you to do IO directly without declaring it in your type, so you don't need the IO monad.

My suggestion would be to focus on standard functional programming in Clojure. Unless you see that you really need monads then I wouldn't invest too much time in trying to bring them in.

Macros are a slightly different issue: they are for compile-time code generation and extensions to the language syntax (which might include DSLs, although DSLs don't necessarily need macros). I use macros when both of the following are true:

1. I want to extend the language syntax in a way that significantly improves my ability to address a particular problem domain.
2. I can't get the same functionality with normal functions / function composition. Normal functions should be your first choice if possible: they are usually simpler to write and maintain.

P.S. If you are genuinely interested in monads for Clojure, here are two videos I personally found quite good:

• http://vimeo.com/20717301 (Brian Marick's excellent visual explanation of monads)
• http://www.infoq.com/presentations/Monads-Made-Easy

Answer 2

Monads and macros have nothing in common. They are used for solving different problems. In Clojure, the monad library uses macros quite extensively for implementing the syntactical "user interface" to monads. You may well use monads to implement some library's functionally and than add a layer of macros for the external interface.

As for "when would one use monads in Clojure", I see two use cases:

1) To implement stuff that makes sense in more than one monad, in order to do the job only once and "plug in" the monad later. Here is a nice illustration of this approach, though unfortunately (from a pedagogical point of view) for a rather non-trivial application: logic programming.

2) To implement a composition technique that can be formulated as a monad, in order to profit from the existing monad infrastructure.

Clojure has two built-in monads, "let" (identity monad) and "for" (sequence monad). Whenever you wish you could plug one of them into your code later on, you should use "domonad" instead. And whenever you wish you had something similar but not quite the same, you should consider writing your own monad.

This remains rather abstract, unfortunately. There aren't many published and polished code examples that use monads in Clojure at this moment. As more Clojurians get familiar with monads and more monad experts (usually coming from Haskell) use Clojure, this is likely to change. I have seen (but don't have at hand) monadic parsing done in Clojure, for example.