After reading the bibliography, I kind of understand that a monad is a unit of calculation with three characteristics:

1. it is a type (or has a type?)
2. it has a unit function, which returns an instance of the monad itself (kind of static constructor)
3. it has the capability to bind itself (with other monads? I guess so)

I’ve been possibly imprecise here, maybe even wrong. But I provide examples in good faith and I make myself easily falsifiable.

It would be tempting to put at least 2. and 3. as method definitions inside an interface Monad, but I have seen that this makes the implementations needlessly complicated. On the contrary, by imposing just one method:

public <B> Monad<B> f(A anA);

in the interface of Monad<A> instead of two methods, I believe I can express the monadic nature to a great extent. This is at this moment my main direction of study (100725).

---

Implementing the three characteristics in Java

1) The type

In Java I can express the monad as a type by just making it generic (i.e. Monad<A>). [1] talks even about Monad<List>, but this is something I still have to grasp; I also believe you can’t make javac digest such a syntax.

2) The unit function

I can implement a unit function in Java with a method

Monad<A> unit(final A anA){return new MonadImpl<A>(anA);}

The trick lies all in the class MonadImpl, which depends on the situation.

3) The bind function

The bind function chains monads. If this is wrong, I’ll change this paragraph. At this moment my intuition tells me that monads are gonna be the main character on stage.

My intuition tells me that Erlang actors are monads. People tell me those little swedish things perform their own single operation (in a stateless mode? I guess so) and pass the buck to the next in the chain. So, let’s chain monads and see if the secret of truly reusable/scalable/thread-safe code will be unveiled!

(Apocalisp shows how to put Functional Java monads at work in parallel; I guess it’s all about the same concepts, but I still have to get there.)

---

OK …three characteristics. So what?

Apart from the three laws mentioned so far, I reckon we ought to find monads something useful to do.

A Monad<A> operates on instances of A. It is not clear to me if there are prescriptions on the type of the result of such operation. The examples in Haskell you can find on the Net always return another monad (called Maybe, Either, etc). I am not aware of an example of a Monad<Integer> returning a plain String. I believe this has to do with exploiting the advantages of lazy calculation.

An F<A,Monad<B>> is itself a monad(*). This fact is exploited by [3] in the example of the Partial class, which I managed to bind in a seemingly comprehensive manner (I will make a page about the Partial class asap).

My intuition tells me that every Monad<A> is an F<A, Monad<?>>, but I cannot follow this completely through.

---

Monads a la carte (using Scala)

Some insights on the nature of the processing done by bind have come to me from using Scala, where it is called flatMap.

Monads are chainable units of computation. Any Scala class can become part of a monad chain. To be allowed in, it has to bring to the party an implementation of flatMap.

Here is my example of etherogenous Scala monad chain at work!!

This subject is gonna be enlarged further.

---

Monad Types (in Java)

A close look at each type should give comprehension of the whole:

• Maybe monad in Java
• State monad in Java
• Thrower/Partial monad in Java

---

(*) an F<X,Y> features a method Y f(X anX)

Bibliography:

[1] Tony Morris – What Does Monad Mean?

[2] Spencer’s Blog – Monads in Java

[3] Apocalisp – Thrower is a Monad