Random Acts of Software Development

Why is Monoid?

2022-01-07T00:00:00+00:00

Monoid is fairly easy to understand, even if you’re just starting out in functional programming. First, you need to understand what a Semigroup is. The Cats definition is very accessible:

If a type A can form a Semigroup it has an associative binary operation.

trait Semigroup[A] {
  def op(x: A, y: A): A
}

And associativity means that elements can be combined using op in random order:

op(a, op(b, c)) == op(op(a, b), c)

The classic example is the addition of integers:

val sumInt: Semigroup[Int] = new Semigroup {
  def op(x: A, y: A): A = x + y
}

The op binary operator of sumInt is associative because (1 + (2 + 3)) = ((1 + 2) + 3).

By contrast, subtraction of integers is not a valid example of a semigroup, because even though the - operator is binary, it is not associative: (3 - (2 - 1)) =/= ((3 - 2) - 1).

Now that we understand Semigroup, we can introduce Monoid. To borrow from Cats again:

Monoid extends the power of Semigroup by providing an additional empty value.

trait Monoid[A] extends Semigroup[A] {
  def id: A
}

The empty value, also known as ‘identity’ value, is such that when used in op, the output is no-op.

For example, addition of integers forms a monoid, because not only is its binary operation associative, but it also has 0 as the identity element: 1 + 0 = 1.

Other monoid examples include multiplication of integers (with id of 1) and concatenation of strings (with the empty string "" as identity element).

When you read about these concepts through the lens of functional programming or mathematics / category theory, it’s easy to be left with the impression that things like semigroup and monoid just exist, and we are simply discovering and describing them. But of course there’s another way of looking at them: that they are invented by us, and we’ve invented them such as they are for a reason.

So what is the reason that Semigroup must have an associative operator? And why does Monoid need an identity element?

To understand this, let’s look at an example.

Take a nested list of values, like List(List(1, 2, 3), List(4, 5)). We might want to collapse this into a single value, by applying some operation to the values in each inner list, and then combining the intermediate results using the same operation. For example, maybe we want to calculate the total sum. So first, we’d want to sum 1, 2 and 3; then we’d want to sum 4 and 5; and finally we’d want to sum the results of these calculations to get a total of 15.

We might also want to make this function generic, so that it works not only with integers and addition, but any value A and any operation that takes two As and returns an A. foldLeft seems a good choice for implementing this function, which means we’ll also need a default value:

def func[A](l: List[List[A]], default: A)(combine: (A, A) => A) =
  l.map(_.foldLeft(default)(combine)).foldLeft(default)(combine)

This seems to work fine for calculating the sum of integers, and we can see that it produces the same result as flattening the list and then adding all the values together:

val l = List(List(1, 2, 3), List(4, 5))

func(l, 0)(_ + _)
// 15: Int

l.flatten.foldLeft(0)(_ + _)
// 15: Int

But what if instead of 0, we chose 1 or -1 as the default value?

func(l, 1)(_ + _)
// 18: Int

l.flatten.foldLeft(1)(_ + _)
// 16: Int

func(l, -1)(_ + _)
// 12: Int

l.flatten.foldLeft(-1)(_ + _)
// 14: Int

So, for func(a) and a.flatten.foldLeft to have the same result, we need the default value to be such that when we use it in combine the output is a no-op. Which is the very definition of the identity function in Monoid!

If we wanted to simplify func, we could abstract the default and combine parameters into some structure, and that structure would be a Monoid:

def func[A](l: List[List[A]])(m: Monoid[A]) =
  l.map(_.foldLeft(m.id)(m.op)).foldLeft(m.id)(m.op)

In other words, Monoid needs an identity function, so that it can be used for operations like the one in func: where we apply some combine function first to the inner members of a nested structure, then on the results from the first pass.

And why does op need to be associative?

If we think about where we might have nested structures like List(List(1, 2, 3), List(4, 5)), one frequent use case is in parallel computing. We might start with a very big collection of some values, and instead of going through it element by element, we might want to first break it into multiple smaller collections, which can then be processed in parallel. The intermediate results are ultimately combined together. (An example of this is MapReduce.)

The thing is, if we started with a List(1, 2, 3, 4, 5) and wanted to apply a MapReduce, we’re not guaranteed to get the data partitioned as List(List(1, 2, 3), List(4, 5)). It might be List(List(1, 2), List(3, 4, 5)). Addition of integers is an associative operation but if we instead apply a non-associative one, we see that the result is different, depending on how the data was partitioned initially:

val l1 = List(List(1, 2, 3), List(4, 5))
val l2 = List(List(1, 2), List(3, 4, 5))

func(l1, 0)((f, s) => (f + s) / 2)
// 2: Int

func(l2, 0)((f, s) => (f + s) / 2)
// 1: Int

So, in order for MapReduce to work with multiple ‘reducers’ in parallel, the reduce function needs to be associative, to guarantee the same result, regardless of the order in which partitions are reduced.

F[A] is ‘F of A’ but what is asRight[A]?

2021-06-11T00:00:00+00:00

A few times I’ve fallen into the trap of making incorrect assumptions about what a type is based on how I read it in my head. Most recently, this happened with the asRight and asLeft wrappers of cats.Either.

Lo:

import cats.implicits._

case class Bad(i: Int)
case class Good(i: Int)
type Parsed = Either[Bad, Good]

def check(value: Int): Parsed =
  if (value >= 0) Good(value).asRight[Bad] else Bad(value).asLeft[Good]

check(0)
// val res0: Parsed = Right(Good(0))

check(1)
//val res1: Parsed = Right(Good(1))

check(-34644425)
// val res2: Parsed = Left(Bad(-34644425))

At first glance, I was surprised that it compiles, because it appeared that in the check function we’re wrapping the results the wrong way around: the Good results as a Bad and vice versa.

Of course, it’s clear from the signatures of asRight and asLeft that it’s not the case:

  /**
   * Wrap a value in `Left`.
   */
  def asLeft[B]: Either[A, B] = Left(obj)

  /**
   * Wrap a value in `Right`.
   */
  def asRight[B]: Either[B, A] = Right(obj)

The type parameter B in either case is the type of the value that goes on the ‘opposite’ side of the Either.

It makes sense, if you think about it. The wrapper already knows what type the wrapped value has because it has access to it. The information that it is missing is what the alternative is.

The reason for my confusion is that in my head when I read the code of check it goes like this: “If the value is greater than or equal to zero then create an instance of Good with the value and wrap it in a Right of Bad, otherwise create an instance of Bad and wrap it a Left of Good.” These ‘Right of Bad’ and ‘Left of Good’ are a natural extension of the reading ‘F of A’ when faced with an F[A]. But they are misleading in this case. In this case, the proper reading is actually ‘Right with a Left of Bad’ / ‘Left with a Right of Good’.

A more intuitive signature for the asRight and asLeft wrappers would be something along the lines of asEither[Left, Right], which has its own downsides.

Should `flatMap` be called `mapFlat`?

2021-03-12T00:00:00+00:00

The name of flatMap might trick you into thinking that it is the same as flatten followed by map. But it’s exactly the other way around: it’s map followed by flatten.

Behold:

List(List(1, 2, 3), List(4, 5, 6)).flatten.map(_ + 1)
// res5: List[Int] = List(2, 3, 4, 5, 6, 7)

List(List(1, 2, 3), List(4, 5, 6)).flatMap(_ + 1)
// If _.flatMap(f) was the same as _.flatten.map(f), this should work in the same way.
// Instead, we get:
//  type mismatch;
//  found   : Int(1)
//  required: String
//  List(List(1, 2, 3), List(4, 5, 6)).map(_ + 1).flatten

List(List(1, 2, 3), List(4, 5, 6)).map(_ + 1).flatten 
// Same result as with flatMap: 
//  type mismatch;
//  found   : Int(1)
//  required: String
//  List(List(1, 2, 3), List(4, 5, 6)).map(_ + 1).flatten

For flatMap to work in this example, it needs to be passed a function that can be applied to List, eg:

List(List(1, 2, 3), List(4, 5, 6)).flatMap(0 :: _)
// res6: List[Int] = List(0, 1, 2, 3, 0, 4, 5, 6)

But not something that reduces the List to an un-flattenable value:

List(List(1, 2, 3), List(4, 5, 6)).flatMap(_.sum)
// type mismatch;
// found   : Int
// required: scala.collection.GenTraversableOnce[?]
// List(List(1, 2, 3), List(4, 5, 6)).flatMap(_.sum)

Beware `java.nio.ByteBuffer` mutability

2021-03-02T00:00:00+00:00

According to the documentation for java.nio.ByteBuffer.wrap(array):

Wraps a byte array into a buffer.
The new buffer will be backed by the given byte array;
that is, modifications to the buffer will cause the array to be modified
and vice versa.

Every time you operate on a ByteBuffer, you modify it.

Here’s an example comparing how ByteBuffer behaves vs Array[Byte]. Imagine you receive binary data (such as Thrift-encoded records), which you want to process and then write to a message queue.

import java.nio.ByteBuffer

// a single record received from upstream
val msgBytes: Array[Byte] = "I am a test message.".getBytes()

// the same record wrapped in a ByteBuffer
val msgBuff: ByteBuffer = ByteBuffer.wrap(msgBytes)

// scenario A: a stream of records wrapped in a ByteBuffer
val batchA = List.fill(3)(msgBuff)
val resultA = batchA.map(m => new String(java.util.Base64.getEncoder.encode(m).array))
println(resultA) // List(SSBhbSBhIHRlc3QgbWVzc2FnZS4=, , )

// scenario B: a stream of records kept as Array[Byte]
val batchB = List.fill(3)(msgBytes)
val resultB = batchB.map(m => new String(java.util.Base64.getEncoder.encode(m)))
println(resultB) // List(SSBhbSBhIHRlc3QgbWVzc2FnZS4=, SSBhbSBhIHRlc3QgbWVzc2FnZS4=, SSBhbSBhIHRlc3QgbWVzc2FnZS4=)

Using `foldRight` instead of `map`

2021-02-11T00:00:00+00:00

Say you want to implement a function add1 that takes a list of integers and adds 1 to each one, so that:

add1(List(1, 2, 3)) == List(2, 3, 4)

This is trivial with map but can add1 be implemented in terms of foldRight?

The signature of foldRight has two type parameters A and B:

foldRight[B](z: B)(op: (A, B) => B): B

There is some implicit knowledge that is required here to fully understand that signature. Firstly, A and B can be the same type, eg an Int. Secondly, foldRight operates on collections, such as List, collapsing them to a single value. A is the type of each element in the collection.

If we think about turning List(1, 2, 3) into List(2, 3, 4), we might fall into the trap of thinking that we need to “get into” the list and then traverse over each element in turn by applying a function to it. That is certainly what map would do, but it is incorrect with foldRight. What foldRight does is it traverses over the elements of the list, applying a function, but adds the result of that operation to an accumulator until ultimately all elements are processed and the final value of the accumulator is returned. This can be seen in its signature, where B is the type returned by the function that is being applied (op) and also the return type of the outer foldRight function. It is also the type of z, the initial value of the accumulator.

So, to implement add1 in terms of foldRight, we need to collapse the original list into a single value, which in this case happens to be another list, with the same number of elements which also have the same type:

def add1(l: List[Int]): List[Int] =
  l.foldRight(Nil: List[Int])((x, y) => (x + 1)::y)

The parameter y is the accumulator. It starts at Nil and then each element of the original list is prepended to it after getting incremented by 1. Since foldRight is not tail-recursive, it will first prepend the last element of the original list to the accumulator, then the second to last, etc.

Another way to implement add1 without using map is to write a recursive function that pattern-matches the original list. The pattern-match will have two branches, one for the base case (which here would be the empty list Nil) and a recursive branch for a non-empty list:

def add1(l: List[Int]): List[Int] = l match {
  case Nil => Nil
  case h::t => (h + 1)::t
}

So any time we have a pattern-match of this kind:

l match {
  case Nil => ???
  case h::t => ???
}

where l is some List-like collection, we can replace it with foldRight. The base-case branch is what our z would be and the non-empty case branch would be op that adds values on top of z, both ultimately returning the same type.

Naming things is hard

2021-01-24T00:00:00+00:00

I recently realised that ambiguous argument naming has been a major obstacle for me building intuition about how foldRight works in Scala.

To illustrate, here’s a simplified definition of foldRight:

def foldRight[A, B](as: List[A], z: B)(f: (A, B) => B): B =
  as match {
    case Nil => z
    case h::t => f(h, foldRight(t, z)(f))
  }

and here’s a function implemented in terms of foldRight:

def doubleToString(l: List[Double]): List[String] =
  foldRight(l, Nil:List[String])((h, t) => h.toString::t)

(These examples come from the exercises in the awesome Functional Programming in Scala by Paul Chiusano and Runar Bjarnason.)

Both of these functions operate on a List and they both in some way de-structure the list to its head and tail. Their signatures also include arguments named h and t in their inner scope. It is the naming of these arguments that is at the root of the challenge. Intuitively, when reading the definition of doubleToString, I expand h to head and t to tail. But, while this expansion is valid for h in both function definitions, it is only valid for t in the definition of foldRight. In the definition of doubleToString, t actually means not tail but rather foldRight(tail, Nil)((head, a) => head.toString::a). The a in that last snippet can itself be recursively replaced with foldRight(a.tail, Nil)(...). It is this recursion, which is part of the definition of foldRight, that causes the trouble. If all I see is the definition of doubleToString, it is not obvious to me that this recursion exists. I must remember that foldRight is a recursive function and that t in doubleToString is also recursive.

My issue with h and t in the definition of doubleToString is that the instinctive expansion to head and tail, drilled into me by so many other occurrences of this shorthand, prevents me from clicking through and checking the definition of foldRight. I make incorrect assumptions, which lead to incorrect interpretations.

By contrast, naming the argument something like a forces me to investigate, or else I would have no idea what it is. I can no longer automatically assume that it has anything at all to do with the List l:

def doubleToString(l: List[Double]): List[String] =
  foldRight(l, Nil:List[String])((h, a) => h.toString::a)

To make it even clearer, a can be called something like acc (for accumulator), which hints at its recursive nature.