理解monad在现实世界中的应用

Question

I'm studying functional programming in Scala and I learnt term monad. In short monad is:

trait M[A] {
  def flatMap[B](f: A => M[B]): M[B]
}

def unit[A](x: A): M[A]

I know monad is just a concept based on above 2 rules. And we can meet many monads in real world such as List , Future ....

The only one problem I don't know is: why should we know term "monad" as comparing to understanding List apis, Future apis or anything apis ... Is understanding monad help us write better code or can design better functional code structure.

Thanks

Answer 1

Because Monad already is a known term in category theory. There are also 3 very important Monad laws, that a Monad has to adhere to.

In theory, we could call Monads whatever we'd like, ie "FlatMappable" or "Bindable", but the name "Monad" is already an established term in the functional programming community and is deeply linked to the Monad laws.

As to why you should learn to appreciate Monads over learning each api individually, it's all about abstraction and reuse of knowledge. Oftentimes when we look at a new concept we compare them to concepts we already know.

If you already understand the Future Monad, understanding the Task Monad will be much easier.

It's also good to mention, that for-comprehensions in Scala work exclusively on Monads. In fact for-comprehensions are just syntactic sugar for flatMap and map (there's also filter , but that's not incredibly relevant to Monads). So recognizing if something is a Monad instance, enables you to utilize this extra piece of syntactic sugar.

Also once you fully grasp the abstraction you can make use of concepts like Monad transformers, where the actual type of the Monad is less important.

Lastly, here are the Monad laws for completeness sake:

• Left identity: M[F].pure(x).flatMap(f) == f(x)
• Right identity: m.flatMap(pure(_)) == m
• Associativity: m.flatMap(f).flatMap(g) == m.flatMap(x => f(x).flatMap(g))

Answer 2

About Monad API vs concrete APIs:

An example could be Free Monad pattern. It essentialy uses (at least) two monads: first one is wrapping your DSL's expressions, and the second one is effect monad, that is, modality that you interpret your expressions in (Option corresponds to something that could fail, Future also adds latency etc).

To be more concrete: consider a task where you have some latency, and you decide to use Futures. How will you unit test that? Return some futures and then use Await? Apart from adding unnecessary complexity, you can run into some problems with that. And you won't actually need to use Futures for some tests. The answer is to parametrize methods that are supposed to use Futures with Monad, so you can just use Identity monad, or Option, and just forget about aforementioned problem.