Name: PHP: monads
Rating: 1.5 (7771 reviews)
Author: spo0q

This post is heavily inspired by the tech talk by Gina Banyard at the "FORUM PHP 2024":

Forum PHP 2024

spO0q 🐒🎃 ・ Oct 13

#php #programming #techtalks

Demystifying Monads with 3 simple synonyms

Let's start with a few synonyms:

containers
wrappers
design patterns

If you google "PHP monads," other concepts will pop quickly, like functional programming, binding, stacks, and even esoteric maths (e.g., functor, monoids).

Don't be scared.

At its core, a Monad is a pattern that can be implemented in various ways.

Design patterns

When you have some operations to run, you may simply define custom objects and helpers, as usual.

So, why bother with alternative concepts?

IMHO, it's still a good question, as you need to stay efficient, but there are common limitations with classic approaches:

the order of operations matters
WET code
exceptions

Monads may handle optional (or not yet available) values more consistently.

Monad vs. classic error handling/exceptions

Modern projects include tools for static analysis, but PHP exceptions are not typed.

In other words, the tools cannot detect exceptions in the function signature, so it cannot determine whether the code handles exceptions correctly.

To test that, dev teams usually write functional tests, but early detection with static analysis would be more reliable.

Source: "Les Exception : le trou dans la raquette du typage" (fr)

With Monads, you get a typed object in all cases, for example, a custom enum case (e.g., FileErrors::AccessDenied), so the error is typed in the system.

Implementing the Logger Monad

Building a robust logging system can be challenging. It's easy to duplicate strings and calls.

Instead of hard coding everything, you would probably define a custom helper called log() and use it everywhere in your project.

This would aim to keep the code DRY but may not allow composing more complex functions in specific cases.

The functional approach would not consist of using such global helper. Instead, it would rather implement a Monad to wrap other functions:

final class LoggerMonad {
    public function __construct(
        public mixed $data,
        public array $logs = [],
    ) {}

    public function bind(callable $fn) {
         $resultLoggerMonad = $fn($this->data);
         return new LoggerMonad(
             $resultLoggerMonad->data,
             [...$this->logs, ...$resultLoggerMonad->logs],
         );
   }
}

function loggify(callable $fn): Closure {
    return function ($value) use ($fn) {
        $name = (new ReflectionFunction($fn))->name;
        $log = [
            'Running '. $name .'('. var_export($value, true) .')'
        ];
        return new LoggerMonad($fn($value), $log);
    };
}

Then, you may use the loggify wrapper like that:

function add2(int $v): int {
    return $v + 2;
}

function square(int $v): int {
    return $v * $v;
}

function multi3(int $v): int {
    return $v * 3;
}

function logIt($value, callable ...$fns) {
    $logging_fns = array_map(loggify(...), $fns);
    $monad = new LoggerMonad($value);
    foreach ($logging_fns as $fn) {
        $monad = $monad->bind($fn);
    }
    return $monad;
}

print_r(logIt(
   3,
   add2(...),
   square(...),
   multi3(...)
));

Source: "Monades simplement" by Gina Banyard (fr)

What is `bind`?

🎵🎵 Baby don't hurt me

Monads are meant to wrap values, which could be any type, including objects and functions.

Like in any other wrapping system, you will find a constructor (~ class) that takes this value as input and some methods that have their own purposes according to the pattern you are trying to implement.

However, all Monads include a bind function. As the name suggests, this is where the values (or callbacks) are passed.

Whatever happens in those callbacks, the monad will wrap it, which is seems a powerful way to decorate values and refactor the code.

Is the code more readable?

It clearly depends on the implementation, and it's easy to get lost at the beginning.

However, this alternative approach can reduce the amount of if blocks significantly, and make return values more consistent:

/** 
 * @return Option<User> 
 */
function getUserById(int $id): Option {
  /** 
   * @var User|null $user 
   */
  $user = $db->getUser($id);

  return Option::fromNullable($user);
}

Source: fp4php - monads

Pros & cons

Pros

✅ there are various monads for different purposes : Maybe, Either, Logger, List, Reader, etc
✅ monads allow wrapping code with better types, which may improve static analysis
✅ PHP does not provide built-in constructs for that, so the implementation is completely up to the developer

Cons

❌ PHP does not provide built-in structures (e.g., Generics) for that, so the implementation is completely up to the developer
❌ it does not simplify the code

Going further

Wrap up

Hopefully, you know now a little bit more about PHP monads.

Of course, you should not add fancy design patterns to your project just for the sake of it.

Besides, it's easy to miss the point and focus on very specific aspects, such as error handling, while it's a whole new paradigm.

However, it's still refreshing to discover new approaches. We need to think out of the box.

PHP: monads