FP in Scala devotes multiple chapters to monads. The Scala standard library uses them everywhere: `Option`, `List`, `Try`, `Either`, `Future`. Understanding the abstraction unlocks why `for`-comprehensions work universally. ## What's a monad? A monad is a type `M[A]` with two operations: 1. **`unit` (or `pure`/`apply`)**: `A => M[A]` — wrap a value 2. **`flatMap`**: `M[A] => (A => M[B]) => M[B]` — chain operations Plus laws: identity, associativity. The names matter less than the SHAPE. ```scala // Option as a monad: Some(5) // unit (via apply) Some(5).flatMap(n => Some(n * 2)) // flatMap // List as a monad: List(1, 2, 3).flatMap(n => List(n, n * 10)) // List(1, 10, 2, 20, 3, 30) // Future as a monad: future.flatMap(value => anotherFuture(value)) ``` ## Why this matters: for-comprehensions Any type with `flatMap`, `map`, and `withFilter` works in a `for`-comprehension: ```scala // Option monad for { a <- userById(1) // Option[User] b <- emailFor(a) // Option[String] c <- domainOf(b) // Option[String] } yield c // Returns Option[String]; None if any step failed // Future monad for { user <- fetchUser(1) orders <- fetchOrders(user.id) } yield render(user, orders) // Returns Future[String] // List monad — Cartesian product for { x <- List(1, 2, 3) y <- List('a', 'b') } yield (x, y) // List((1,a), (1,b), (2,a), (2,b), (3,a), (3,b)) ``` Same syntax, different effects: - Option: "missing value short-circuits" - Future: "async chained operations" - List: "for each combination" - Either: "failure short-circuits" - Try: "exception short-circuits" ## Implementing your own monad-like type For a `Box[A]`: ```scala case class Box[A](value: A) { def map[B](f: A => B): Box[B] = Box(f(value)) def flatMap[B](f: A => Box[B]): Box[B] = f(value) } val result = for { a <- Box(2) b <- Box(3) } yield a + b // Box(5) ``` Define `map` and `flatMap` correctly and you join the for-comprehension club. ## The monad laws (briefly) 1. **Left identity**: `unit(x).flatMap(f) === f(x)` 2. **Right identity**: `m.flatMap(unit) === m` 3. **Associativity**: `m.flatMap(f).flatMap(g) === m.flatMap(x => f(x).flatMap(g))` When these hold, your type is a real monad and composes predictably. If they don't, weird bugs in for-comprehensions. ## When to define a monad? - Your type has a sequencing semantic (do this, then that) - You want for-comp ergonomics for users - You're building an effect type (IO, State, Reader, Writer) **Don't reach for monads** for simple data containers. Use case class. Monads are for things with sequenced effects. ## Cats and ZIO The **Cats** library generalizes this: `Functor`, `Applicative`, `Monad` as type classes. `IO`, `Reader`, `State`, `Writer`, `EitherT` as concrete monads. Cats Effect 3 / ZIO 2 are the modern functional effect systems for Scala — heavyweight ecosystems that build on the monad abstraction. ## Common mistakes - **Confusing `map` with `flatMap`** — map for `A => B`; flatMap for `A => M[B]`. flatMap also "flattens" the result. - **Implementing flatMap with side effects** — breaks the laws. flatMap should be pure transformation. - **`for` loops vs for-comp** — `for (x <- list) print(x)` is iteration (no yield); `for { ... } yield ...` is monadic. - **Nested Future in flatMap result** — use flatMap, not map. `m.map(f)` where f returns Future gives `Future[Future[X]]` instead of `Future[X]`. - **Reaching for Cats/ZIO without understanding the basics** — learn the standard-library monads first.

Scala Advanced

Curriculum