Demystifying the Trinity: Functor, Applicative, and Monad in PureScript
When diving into pure functional programming, you are immediately confronted with three abstract terms that sound more like advanced physics concepts than software engineering patterns: Functors, Applicatives, and Monads.
For a long time, the internet has tried to explain them using metaphors like "burrito boxes" or "spaceships." Based on my experience and everyday usage, it is much better to look at them for what they truly are: elegant design patterns for managing data flow, context, and computation with mathematical certainty.
Let’s break down this holy trinity of functional programming using clean, practical PureScript examples.
The Core Concept: Values in a Context
Before writing code, let’s establish a visual mental model. In PureScript, we often deal with values wrapped inside a context (or container).
Maybe arepresents a value of typeathat might be missing (handlingnullsafely).Either e arepresents a computation that might fail with an error of typee.Effect arepresents a synchronous side-effect (like logging to the console or interacting with the DOM).
The Trinity—Functor, Applicative, and Monad—are simply a progressive set of tools that allow us to manipulate these wrapped values without manually unwrapping and re-wrapping them at every single step.
1. Functor: Mapping over a Context
The simplest abstraction is the Functor. A Functor allows you to apply a normal, pure function to a value that is sitting inside a context.
The Definition
To be a Functor, a type constructor f must implement the map function (often written as the infix operator <$>).
Code snippet
class Functor f where
map :: forall a b. (a -> b) -> f a -> f b
Usage Example
Imagine you are processing a transaction payload where the payment amount might be missing (Maybe Int). You want to convert this amount into cents (multiply by 100).
Code snippet
module Main where
import Prelude
import Data.Maybe (Maybe(..))
import Effect (Effect)
import Effect.Console (logShow)
-- A pure function that knows nothing about contexts
toCents :: Int -> Int
toCents dollar = dollar * 100
main :: Effect Unit
main = do
let dynamicAmount = Just 50 -- A value inside a context
let missingAmount = Nothing -- An empty context
-- Using map (<$>) to apply the pure function inside the context
logShow (toCents <$> dynamicAmount) -- Output: (Just 5000)
logShow (toCents <$> missingAmount) -- Output: Nothing
Crucial Insight: Notice how toCents takes a raw Int, not a Maybe Int. The Functor instance for Maybe automatically handles the plumbing. If it’s Just, it applies the function. If it’s Nothing, it short-circuits safely.
2. Applicative: Function and Value Both in Contexts
What happens if the function itself is trapped inside a context? Or what if you want to apply a pure function that takes multiple arguments to multiple wrapped values? This is where Functor falls short, and Applicative steps in.
The Definition
An Applicative Functor extends Functor with two main functions: pure (to lift a raw value into a context) and apply (written as <*>).
Code snippet
class Functor f <= Applicative f where
pure :: forall a. a -> f a
apply :: forall a b. f (a -> b) -> f a -> f b
Usage Example
Suppose we are building a user profile record from an API response. We have a pure data constructor createUser that takes a String (Name) and an Int (User ID). However, both pieces of data are fetched independently and arrive wrapped in a Maybe context.
Code snippet
type User = { name :: String, id :: Int }
createUser :: String -> Int -> User
createUser name id = { name: name, id: id }
main :: Effect Unit
main = do
let maybeName = Just "Alice"
let maybeId = Just 1024
-- Functor + Applicative in harmony:
-- 1. `createUser <$> maybeName` maps the first argument, returning: Maybe (Int -> User)
-- 2. We use `<*>` to apply the remaining wrapped Int argument.
let maybeUser = createUser <$> maybeName <*> maybeId
logShow maybeUser
-- Output: (Just { name: "Alice", id: 1024 })
-- If any piece is missing, the whole thing safely results in Nothing
let partialUser = createUser <$> Nothing <*> maybeId
logShow partialUser
-- Output: Nothing
Crucial Insight: Applicatives allow you to run independent computations in isolation. The evaluation of maybeId does not depend on the result of maybeName.
3. Monad: Dependent Chaining (The Heavy Lifter)
Finally, we reach the Monad. While Applicatives handle independent wrapped values, Monads are designed to handle dependent sequential computations.
Use a Monad when the output of one context-wrapped computation determines what the next context-wrapped computation should look like.
The Definition
A Monad extends Applicative by introducing bind (written as >>=).
Code snippet
class Applicative m <= Monad m where
bind :: forall a m b. m a -> (a -> m b) -> m b
If you tried to use regular map with a function that returns a wrapped value (i.e., a -> m b), you would end up with a messy nested context: m (m b). The Monad’s job is to apply the function and automatically flatten the result.
Usage Example (PureScript do notation)
PureScript provides syntactic sugar called do notation, which makes working with Monads look like imperative code while preserving pure functional guarantees under the hood.
Let's look at a typical multi-step verification sequence:
Validate a user ID.
If valid, look up their wallet balance (which could fail).
If they have enough funds, process the transaction.
Code snippet
import Data.Maybe (Maybe(..))
-- Simulating dependent lookups
validateUser :: Int -> Maybe String
validateUser id = if id == 777 then Just "VIP_User" else Nothing
getWalletBalance :: String -> Maybe Int
getWalletBalance username = if username == "VIP_User" then Just 500 else Nothing
-- Monadic Chaining using `do` notation
processPayment :: Int -> Maybe String
processPayment userId = do
username <- validateUser userId -- Extracts string out of Maybe
balance <- getWalletBalance username -- Dependent on previous username
if balance > 100
then Just "Payment Successful!"
else Nothing
main :: Effect Unit
main = do
logShow (processPayment 777) -- Output: (Just "Payment Successful!")
logShow (processPayment 123) -- Output: Nothing (Fails safely at step 1)
Crucial Insight: If validateUser returns Nothing, the Monad stops evaluating the rest of the block immediately. We get bulletproof error propagation without writing a single nested if-else or try-catch block.
Summary: Choosing Your Tool
In my day-to-day workflow, I pick the right tool for the job by asking a simple question about what I am trying to combine:
Abstraction | What you have | What you want to apply | Code pattern |
Functor | Value in a context ( | A pure function ( |
|
Applicative | Values in contexts ( | A pure multi-arg function |
|
Monad | Value in a context ( | A function returning a context ( |
|
Final Thoughts
Adopting these typeclasses fundamentally shifts how you reason about software architecture.
Before using this framework, handling multi-step asynchronous or conditional logic meant writing deeply nested error-handling logic. By leveraging Functor, Applicative, and Monad, we compose complex architectures out of small, highly reusable, and predictable building blocks. It makes systems dramatically easier to refactor, impossible to crash with unexpected null pointers, and exceptionally clean to maintain.