The bread and butter of everyday functional programming is the implementation of standard functional combinators for your datatypes.

For example, fluency with the flatMap combinator, also known as >>=, is very important.

The similarity at the type level is obvious, however there are further connections.

When you write functions using flatMap, in any of the varieties above, these functions inherit a sort of sameness from the underlying flatMap combinator.

Gabriel Gonzalez has referred to this sort of composability as the 'catergory theory design pattern'.

Functional Programming in Scala introduces several such functions, such as sequence and traverse.

These are each implemented for several types, each time with potentially the same code, if you remember to look back and try copying and pasting a previous solution.

We would like to follow the DRY principle and parameterize: extract the parts that are different to arguments, and recycle the common code for all situations.

In tuple’s case, what is different are the flatMap and map combinator implementations, and the type constructor: List, Option, State, etc.

We already have a way to swap out different implementations of the flatMap and map combinators.

To generalize the notion of 'tupleability' however, we need to pass type-level functions as arguments.

You could think of this as a kind of type-level parametric polymorphism:

More complicated and powerful cases are available using partial application.

That’s how we can fit State, Either, Reader, Writer and other type constructors with two or more parameters..

The type of tupleF expresses precisely our intent—the idea of “multiplying” two Fs, tupling the values within—but cannot be implemented as written.

That’s because we don’t have functions that operate on F-constructed values, like x: F[A] and y: F[B].

As with any value of an ordinary type parameter, these are opaque.

There are several major problems with the subtyping generalization in Monadic.

These are sufficiently bad to make subtype polymorphism extremely unpopular in the Scala functional community, though you occasionally see it in older code (e.g. Ermine)

First, this pattern can only be applied to classes that we have written ourselves.

Second, the knowledge required to work out the new type signature above is excessively magical: note how much tupleF looked like the List-specific type, and how little tupleF2 looks like either of them.

There are also complex rules about when implicit conversion happens, how much duplication of the reference to Monadic is required to have the F parameter infer correctly, and even how many calls to Monadic methods are performed.

For example, we’d have to declare the F parameter as F[X] <: Monadic[F, X] if we did one more trailing map call. But then we wouldn’t support implicit conversion cases anymore, so we’d have to do something else, too.

Luckily typeclasses provide an elegant solution to constraining higher-kinded types.

Since version 2.8, Scala has provided syntax for implicit parameters, called Context Bounds.

We can remove the implicit F argument, replacing it with a context bound F[_]: Monad in the type argument list.

What's the point of passing an implicit parameter in a context bound but not naming it?

Often, the implicit parameter need not be referred to directly, it will be tunneled through as an implicit argument to another method that is called.

Earlier I mentioned the 'catergory theory design pattern'.

Category theory is a branch of mathematics that grew up around algebraic topology in the mid-20th century, but has been increasingly applied to areas of computer science, particularly type theory.

We can think of a category as a generalized monoid.

Observe that with a monoid M, we can view each element of the monoid as a function of type M => M. For example, in the Int monoid with addition, these elements are (_ + 0), (_ + 1), etc.

Then the composition of these functions is the operation of the monoid.

We can generalize this notion to consider not just the type M, but all types (A, B, C, etc.) and functions not just of type M => M, but A => B for any types A and B.

Then ordinary function composition is an associative operation, with an identity element which is the identity function that just returns its argument.

Monads are one of the most common abstractions in Scala, and one that most Scala programmers are familiar with even if they don’t know the name.

We even have special syntax in Scala to support monads: for comprehensions.

Despite the ubiquity of the concept, Scala lacks a concrete type to encompass monads.

This is one of the many benefits of using Cats.

Formally, a monad for a type M[A] has:

• an operation flatMap with type (M[A], A => M[B]) => M[B]
• an operation pure with type A => M[A].
  
  

pure (often referred to as unit or return) abstracts over the constructor of our monad.

flatMap (often referred to as bind and given the infix notation >>=) chains structured computations together in a way that allows interference between the structure and computation layers.

Most of the type classes we consider in this class are monadic: List, Vector, Option, Xor, State, Future, Parser, Reader, Writer, IO etc.

That means that these type classes all have the above operations, the so-called 'proper morphisms' of a monad,

They also include some 'non-proper morphisms' which give them additional capabilities.

pure and flatMap must obey three laws:

1. Left identity: flatMap pure(a) f == f(a)
2. Right identity: flatMap m pure == m
3. Associativity: flatMap (flatMap m f) g == flatMap m (a => flatMap f(a) g)

We can also state the monad laws in terms of pure, join, and map:

1. Left identity: join(pure(m)) == m
2. Right identity: join(map(m)(pure)) == m
3. Associativity: join(join(m)) == join(map(m)(join))

As an aside, the definition of a monad used in category theory is stated this way.

That is, if we have a value x of type M[M[M[A]]], we can join twice to get M[A], or we can map join over the outer M and then join the result of that.

This is saying that in "flattening" M[M[M[A]]] to M[A], it should not matter whether we first join the two "inner" Ms or the two "outer" Ms.

This is analagous to the monoid associativity law.

In the expression ((1 + 2) + (3 + 4)) + ((5 + 6) + (7 + 8)), it doesn't matter whether we remove the inner brackets first to get (1 + 2 + 3 + 4) + (5 + 6 + 7 + 8) or the outer brackets first to get (1 + 2) + (3 + 4) + (5 + 6) + (7 + 8).

In both cases we end up with 36. The reason it doesn't matter is that + is associative.

Interestingly, a monad itself is a certain kind of monoid.

Think of a type like M[M[_]] => M or M² => M as (M, M) => M (taking 2 Ms or the product of M with itself), and 1 => M as M (where 1 is the Unit type).

Then we can think of a type like M[M[A]] => M[A] as M²[A] => M[A] or just M² ~> M (where ~> denotes a natural transformation).

Similarly, A => M[A] is analagous to 1[A] => M[A] (where 1 is the identity functor) or just 1 ~> M:

The real difference is that Monoid[M] is operating in a category where the objects are Scala types and the arrows are Scala endofunctions, and Monad[M] is operating in a category where the objects are Scala endofunctors and the arrows are natural transformations.

In other words, a monad is a monoid in the category of endofunctors.

See this StackOverflow question and Rúnar's article, "More on monoids and monads" for more information.

Each monad instance we write means something totally different, but the monad laws make similar assertions.

For example we might write a Monad[Future] to constrain the behavior of concurrent processes.

In this case the monad laws would force map to extend a running process by giving its continuation.

The unit and join functions with the monad laws would say that we can arbitrarily fork subexpressions of a program, and arbitrarily join with forked processes, and that the order in which we fork and join doesn’t matter to the result of the program.

Map functions are obvious candidates for essential parts of a usable library for functional programming.

This is a low-order abstraction—it eliminates concrete loops.

When we note a commonality in patterns and define an abstraction over that commonality, we move “one order up”.

Modern general-purpose functional libraries such as Cats have much more than a bunch of map functions, and we will soon find ourselves abstracting over many other, more complex patterns: error-handling (Either), logging (Writer), dependencies (Reader), concurrency (Future), state (State), etc.

Onward and upward!

Finish reading Chapter 11 in Functional Programming in Scala and have a look at the Monad type class in Cats.

• Advanced Scala with Cats
• Higher-Kinded Types
• Typeclassopedia