Inner Product

How to Write an Abstract

2018-04-19T00:00:00Z

How do you write an abstract for a (industry) conference talk proposal? I like to use a three paragraph structure. The first paragraph gives a quick overview of what attendees can expect to learn if they attend the talk. The second paragraph gives motivation and background—why should attendees care about what I have to say? The third and final paragraph goes into more detail on the points I intend to cover.

An abstract is a sales pitch to conference organizers and attendees. Conference organizers need to be convinced to accept the talk, and conference attendees need a reason to attend the talk. Luckily these two groups are looking for the same thing: evidence I have something interesting and coherent to say. Both are also short of time. I hope the organisers spend a bit more time on the abstract than can reasonably be expected of attendees but the quicker I can sell either group the better.

This explains why I want the first paragraph to overview my talk—so attendees who only read that far can decide if they want to attend. The organisers want a bit more detail, so the job in the remaining paragraphs is to convince them that the problem I’m addressing is important (and hence will get an audience) and that I have something to say about it. That’s all I need in an abstract, so three paragraphs should suffice.

If you have read this far you might want an example of the three paragraph structure. If so, you might wish to look over the previous three paragraphs…

Solving the Rubik's Cube with Group Theory and Functional Programming

2019-05-06T17:00:00Z

Introduction

In this series of blog posts, we’ll develop a Rubik’s cube solution from first principles, using group theory and functional programming in Scala. There are already many existing solutions; optimal solutions can be computed in a fraction of a second, and many tutorials are available online that allow humans to solve a Rubik’s cube within 20 seconds. Our goal here will be to develop a solution we can really understand; a solution that’s both simple to express as a program and easy to teach to a human.

That gives us two constraints:

We’ll avoid directly translating speedcubing methods. On one hand, human solutions rely on cube algorithms that have been computed ahead of time and memorized. Simply porting one of these solutions doesn’t really count as “understanding” the solution. On the other hand, human solutions also rely on intuition and different types of moves that are context-dependent. This is very messy to implement as a program.
We won’t search for an optimal solution, or even one with a low move-count. Optimal solutions require deeper mathematical background and large tables of algorithms. Even if a human can be said to understand such a solution, they wouldn’t be able to calculate and execute it.

Instead, we’ll learn about the minimal building blocks we need to invent Rubik’s cube algorithms ourselves. These will be simple and general enough so that we should be able to apply them to any similar mechanical combination puzzle (or “twisty puzzle”).

Overview of topics covered

Our solution will borrow ideas from math and functional programming. The math will help us model our problem and understand our solution. The functional programming concepts will help us express our solution in elegant terms and translate the math into our problem domain. We’ll also borrow ideas and vernacular from twisty puzzle enthusiasts, modifying the math idioms to be more cube-friendly.

Permutations

Every Rubik’s Cube scramble is essentially just a permutation of its stickers and pieces. The Rubik’s Cube is an example of what’s called a “Permutation Puzzle”. You have a small set of scrambling moves (the six face turns), which you need to combine in order to unscramble the greater puzzle.

We’ll learn about permutations, and how they can be be decomposed into smaller permutations and disjoint cycles. We can decompose larger permutations (like scrambles) into smaller cycles and transpositions. We can systematically break puzzles down into smaller problems that are more manageable.

Group Theory

As it happens, the scrambles of a Rubik’s Cube have an underlying mathematical structure called a “group” (The “Rubik’s Group”). This is useful because mathematicians have already been studying groups for centuries. Groups have structure; they’re composed of simpler subgroups that interact with each other. These simpler groups and their relationships are well understood by mathematicians, and we can use existing theorems and techniques to inform how we model both the Rubik’s Cube and its solution.

Additionally, every mathematical group is analogous to a group of permutations, so any problem involving groups structure can be expressed in terms of permutations. Permutations are computationally simple to work with, and we can re-use everything we’ve learned about permutations to work with groups in the abstract.

Along the way, we’ll learn about subgroups, direct products, group actions, and homomorphism. This isn’t technically required to understand the solution, but it still serves as great example of how math can reduce the amount of work to be done by puzzle solvers and programmers alike. This section is for the nerd inside all of us that wants to really grok how things work.

Functional Programming

We’ll tie this all together with functional programming: permutations are a special type of function called a bijection, which means they always have an inverse. We’ll see how these functions can be composed with their inverses in specific ways that allow us to create custom permutations with desirable effects. This will be important, because once we break down a scramble into smaller cycles and transpositions, we’ll need to be able to invent algorithms that solve those smaller problems.

We’ll also learn about how groups relate to existing FP typeclasses that we might already be familiar with (Semigroups and Monoids). This is important because it’ll allow us to leverage techniques and libraries already used and taught by the FP community. In short groups allow us to leverage existing ideas from both Math and Functional Programming to simplify our approach to crafting a solution.

List of Articles:

Part 1: Permutations as Functions
Part 2: The Group Typeclass
Part 3: Cycles, Swaps, and Permutations (upcoming)
Part 4: Cube Algorithm DSL as a Group (upcoming)
Part 5: Combinations, Conjugates, and Commutators (upcoming)
Part 6: Modeling Rubik’s Cube State in Scala (upcoming)
Part 7: Putting it all together (upcoming)

Permutations as Functions

2019-05-06T17:00:01Z

This is the first part of a series of posts detailing the theory behind Rubik’s cube solutions and tying it in to functional programming concepts. Permutations will be a major building block of our solution. In this post, we’ll show how they can be composed, inverted, and treated like functions.

Scrambles of a String

You might have learned to think of permutations as rearrangements of elements in a collection. In Scala, every SeqLike has a .permutations method that will return an iterator over every permutation of its elements. Consider this example from the REPL:

scala> "ABC".permutations.toList
res0: List[String] = List(ABC, ACB, BAC, BCA, CAB, CBA)

We get a list of six strings, all possible permutations of “ABC”. What might not be immediately obvious is that each of these permutations can be identified with a function of type Char => Char that goes from characters in the string "ABC" back to the same string. For example, consider the fourth element, "BCA". It permutes "ABC" by sending 'A' to 'B', 'B' to 'C', and 'C' to 'A'. We can encode this directly as a partial function in scala:

val bca: Char => Char = {
  case 'A' => 'B'
  case 'B' => 'C'
  case 'C' => 'A'
}

This can permute the characters of our original string via .map:

"ABC".map(bca) // "BCA"

So in a sense "BCA" is not just a permutation of "ABC"; it represents the function that permutes "ABC" into "BCA". This function permutes other strings too:

"BCA".map(bca) // "CAB"
"CAB".map(bca) // "ABC"

Even more generally, bca can be thought of as a function permuting any set of three elements. It sends the first to the second, the second to the third, and the third back to the first.

Bijections from a Set to Itself

So, we can use functions of type A => A to model permutations. However, not every function of this type is a valid permutation. Notice how every letter in a string is still present after it’s scrambled. For our function to preserve this property, it needs to pair off all the elements of its domain and range in an exactly one-to-one fashion.

Such functions are called bijective functions, or bijections. It’s “bi” in the sense of “bidirectional”; we can invert our function to send elements from the range back to the domain. Permutations are a special case of bijections where the parameter and result types are the same, so inverting a permutation gives you a function of the same type.

We can construct the inverse of a permutation, but it will be much easier to do so with a Map implementation, versus representing a permutation as a A => A function.

Implementing Permutations with `Map[A, A]`

Our initial encoding via a (Char => Char) function was a bit opaque. We’ll want want to print, compare, and transform our permutations, so to enable this, we’ll model our original six permutations using Map. For simplicity, let’s use a type inhabited by only three values:

sealed trait Point extends Product with Serializable
case object A extends Point
case object B extends Point
case object C extends Point
val allPoints = Set(A, B, C)

A permutation is then a Map[Point, Point]. Here’s a lightweight implementation using a type alias and some constructors:

type Perm = Map[Point, Point]

object Perm {
  def apply(pairs: (Point, Point)*): Perm = {
    require(pairs.map(_._1).toSet == allPoints, s"Domain must be $allPoints.")
    require(pairs.map(_._2).toSet == allPoints, s"Range must be $allPoints.")
    Map(pairs: _*)
  }

  def apply(p: Point => Point): Perm = {
    apply(A -> p(A), B -> p(B), C -> p(C))
  }

  def inverse(perm: Perm): Perm = perm.map(_.swap)
}

Our first constructor constrains our values to valid permutations as discussed earlier. Our second constructor allows us to lift regular functions into our Perm type. Inverting a permutation is done simply by swapping all the tuples in its map.

With this, we can re-implement our original bca example:

val bca = Perm(
  A -> B,
  B -> C,
  C -> A
)

In Scala, Map inherits from Function1, so we can still pass this as a function in .map:

scala> List(A, B, C).map(bca)
res0: List[Point] = List(B, C, A)

Or compose it with itself to perform successive permutations:

scala> List(A, B, C).map(bca compose bca)
res1: List[Point] = List(C, A, B)

scala> List(A, B, C).map(bca andThen bca)
res2: List[Point] = List(C, A, B)

But unlike a regular function, computing its inverse is trivial:

scala> List(B, C, A).map(inverse(bca))
res3: List[Point] = List(A, B, C)

scala> assert(bca == inverse(inverse(bca)))

As seen in the first section, there are only six permutations of three elements. Below we use our model to implement all six of them:

val abc = Perm(
  A -> A,
  B -> B,
  C -> C
)
val acb = Perm(
  A -> A,
  B -> C,
  C -> B
)
val bac = Perm(
  A -> B,
  B -> A,
  C -> C
)
val bca = Perm(
  A -> B,
  B -> C,
  C -> A
)
val cab = Perm(
  A -> C,
  B -> A,
  C -> B
)
val cba = Perm(
  A -> C,
  B -> B,
  C -> A
)

val allPerms = Set(abc, acb, bac, bca, cab, cba)

Now we can compose and sequence these permutations like we can functions. Notice that since we’ve instantiated all possible permutations, the resulting permutation will be equal to one we’ve already computed:

scala> assert(Perm(acb compose bac) == cab)

scala> val bcaTwice = Perm(bca andThen bca)
bcaTwice: Perm = Map(A -> C, B -> A, C -> B)

scala> assert(bcaTwice == cab)

scala> val cabThrice = Perm(cab andThen cab andThen cab)
cabThrice: Perm = Map(A -> A, B -> B, C -> C)

scala> assert(cabThrice == abc)

The same is true when inverting functions. For example, when we invert bca, we get bac, and vice versa:

scala> assert(inverse(bca) == cab)

scala> assert(inverse(cab) == bca)

There two are inverses of each other. This makes sense if you look at their effect on a list. bca cycles the elements to the left, while cab cycles the elements to the right:

scala> List(A, B, C).map(bca)
res4: List[Point] = List(B, C, A)

scala> List(A, B, C).map(cab)
res5: List[Point] = List(C, A, B)

Another way to say this is that composing bca with cab results in the identity permutation, which sends every point back to itself. In our example, that abc:

scala> List(A, B, C).map(abc)
res6: List[Point] = List(A, B, C) // Same list

scala> assert(Perm(bca compose cab) == abc)

scala> assert(Perm(bca andThen cab) == abc)

A permutation can also be its own inverse, as in these examples:

assert(inverse(acb) == acb)
assert(inverse(bac) == bac)
assert(inverse(cba) == cba)

Each of these permutations swaps two elements, so it makes sense that swapping the elements twice results in no action. Lastly, the identity permutation is always its own inverse:

assert(inverse(abc) == abc)

Our original six permutations have gone from scrambled strings to scrambling functions, which can compare, compose, and invert. Now that’s functional programming! In the next post, we’ll see that permutations are essential to an algebraic structure called a Group.

The code used in this post is available in a scastie worksheet:
https://scastie.scala-lang.org/stewSquared/nNx923P0QyOiBaebwLZyJg

The Group Typeclass

2019-05-06T17:00:02Z

In the previous post of this series, we showed that the permutations of a set are functions that can be inverted or composed to give rise to different permutations of the same set. Given these operations, sets of permutations form an algebraic structure called a group.

In this post, we’ll define what a group is, explore its structure, and discuss some examples of groups. We’ll use the Group typeclass and show it’s relationship to other typeclasses. We’ll also show how permutations have a group structure, and that any other group can be described by a permutation group.

An Intuition for Monoids and Groups

You might be familiar with the Semigroup or Monoid typeclasses. Even if you’re not familiar with them by these names, you’re probably very familiar with the concepts they abstract. In a broad sense monoids and semigroups allow us to combine two elements of some type to get another element of the same type. You can add numbers, concatenate strings, merge dictionaries, or compose functions. We’ll cover some examples and more formal definition in the next section.

These typeclasses are extremely useful; libraries like Spire and Algebird use them extensively for numerical and algebraic computation. But sometimes, they’re too general. A more specific abstraction can give us a greater ability to reason about the sets of elements that these combining operations act on. Groups are one such abstraction.

Groups extend monoids to allow decomposing elements. If you’ve used used operations like subtraction, division, factoring, inverting, or undo, then you’ve already worked with groups whether you realize it or not. Consider how heavily you use cancellation to solve or simplify algebraic equations. This is the kind of reasoning power that groups enable. The Group typeclass abstracts this ability, formalizing what it means to cancel out elements from a combination.

Groups are less general than monoids, since not all monoids have a group structure with an operation that can be reversed. But while we lose general applicability of our typeclass, we gain an increased ability to reason about our elements.

Semigroups and Monoids

Semigroup

A semigroup is a set with an associative binary operation. It lets you combine any two elements to get another element of the same type. It’s extremely general; instances are already defined out of the box for many different types. Here are some examples using Cats:

import cats._
import cats.implicits._

Semigroup.combine(1, 2)
// res0: Int = 3

Semigroup.combine("Group", "Theory")
// res1: String = "GroupTheory"

Semigroup.combine(Map('A' -> 10), Map('A' -> 5, 'B' -> 5))
// res2: Map[Char, Int] = Map('A' -> 15, 'B' -> 5)

Cats provides a simplified syntax that we’ll use from here on out:

1 |+| 2 |+| 3
// res4: Int = 6

"Group" |+| "Theory"
// res5: String = "GroupTheory"

Note the fact that the combining operation must be associative, which means the following equality must hold for any x, y, and z.

(x |+| y) |+| z == x |+| (y |+| z)

The operation is also not necessarily commutative; x |+| y is not necessarily equal to y |+| x:

assert(1 |+| 2 == 2 |+| 1) // true for `Int`

assert("Group" |+| "Theory" != "Theory" |+| "Group") // but not for `String`

Monoid

Monoid extends semigroup with the concept of an identity element. Combining an element with the identity results in that same element, (eg., adding zero). This is true whether combining from the left or right:

assert(0 |+| 3 == 3)

assert(3 |+| 0 == 3)

Monoid instances from Cats give us the identity element of a set via .empty:

Monoid[Int].empty
// res6: Int = 0

Monoid[String].empty
// res7: String = ""

In the context of collections, this allows reducing an arbitrary list down to a single element to give a very general definition of a sum:

Monoid[Int].combineAll(1, 2, 3, 4)
// res8: Int = 10

Addition isn’t the only way to define a monoid for integers. We could provide our own definition that uses multiplication, where the identity is 1 instead of 0:

IntProductMonoid extends Monoid[Int] {
  def empty = 1
  def combine(x: Int, y: Int) = x * y
}

IntProductMonoid.combine(3, 5)
// res9: Int = 12

(Note: both the terms “multiplication” and “addition” are used to describe the combining operator of a group, with the latter being reserved for commutative operations. We can disambiguate with “integer multiplication” and “integer addition”, but in this post, we’ll follow Cats and use the the more neutral term, “combination”, denoted |+|)

(Note that without the identity element, we wouldn’t be able to reduce an empty list. eg., in folds, we would have to provide a default case.)

Semigroups and Monoids are both already well-documented in Cats’ page on Type-Classes.

Group: Monoid with Inverse

As monoids extend semigroups with identity elements, groups extend monoids with the concept of inverse elements.

A group requires that every element has a unique inverse. You can combine an element with its inverse to “cancel out” to the identity element. While it’s not as heavily used or documented, Cats does provide a definition. The Group[A] typeclass includes an additional method, def inverse(a: A): A, that maps each element to its inverse. It essentially looks like this:

trait Group[A] {
  def empty: A // identity
  def inverse(a: A): A
  def combine(a: A, b: A): A
}

Cats provides instances out of the box for various numerical types. They can be used like so:

scala> Group[Int].inverse(1)
res0: Int = -1

scala> Group[Int].remove(10, 1)
res1: Int = 9

The existence of inverse elements allows us to implement remove which is the inverse operation to combine. It’s analogous to subtraction, where subtracting b from a really just means adding negative b to a. Removing means combining inverse b with a:

def remove(a: A, b: A): A = combine(a, inverse(b))

Cats also provides an operator syntax for remove that’s reminiscent of subtraction:

scala> 10 |-| 1
res2: Int = 9

scala> 3 |+| 2 |-| 2
res3: Int = 3

Note that our integer multiplication monoid from above isn’t also a group given division, since the inverses (reciprocal fractions) are no longer integers. To form a group with multiplication, we’d need rational numbers or some sort of Fraction type. Floating point division doesn’t quite work here because of rounding. Since the mapping isn’t one-to-one. We get in trouble when we assume it works like a true inverse. In the following example, if division truly gave you the inverse, multiplication and division by 3.0 would cancel out, and we’d get 0.1:

scala> 0.1 * 3.0 / 3.0
res0: Double = 0.10000000000000002

So a group is a monoid with a inverses. This sounds simple, but it actually implies a lot of structure and laws for the set of A, especially when the type is inhabited by a finite number of elements, or the operation is non-commutative.

To understand some of this structure, we’ll need to discuss permutations. If you aren’t already familiar with permutations, and specifically how a permutation is actually a bijective function, go back and read this post before continuing on.

Permutation Groups

Every element of a group can be viewed as a permutation. To illustrate this, we’ll need an example of a small finite group. We’ll use the integers modulo 6 under addition:

case class Mod6 private(value: Int) 

object Mod6 {
  def apply(n: Int) = {
    val mod6 = n % 6
    if (mod6 >= 0) new Mod6(mod6)
    else new Mod6(mod6 + 6)
  }

  implicit object Mod6Group extends Group[Mod6] {
    override def empty = Mod6(0)
    override def inverse(n: Mod6) = apply(-n.value)
    override def combine(m: Mod6, n: Mod6) = apply(n.value + m.value)
  }
}

With this implementation, there are only 6 ways to construct an valid instance of Mod6 using our apply method. In formal terms, the Mod6 group has order 6:

scala> val elements = (-12 to 12).map(Mod6(_)).distinct.toList
elements: List[Mod6] = List(Mod6(0), Mod6(1), Mod6(2), Mod6(3), Mod6(4), Mod6(5))

We can map over all these elements to get a “combination table” of sorts (Analogous to multiplication tables):

scala> val mod6Table = elements.map(m => elements.map(m |+| _))
mod6Table: List[List[Mod6]] = ...

scala> mod6Table.map(_.map(_.value).mkString(" ")) foreach println
0 1 2 3 4 5
1 2 3 4 5 0
2 3 4 5 0 1
3 4 5 0 1 2
4 5 0 1 2 3
5 0 1 2 3 4

Here, each element uniquely determines a row, each of which contains all six elements in a unique order. That is to say, each element corresponds with a unique permutation of the set. If we were to write that out more concretely using our approach from the previous post, our permutations would look something like this:

val twoMod6 = Perm(
  0 -> 2,
  1 -> 3,
  2 -> 4,
  3 -> 5,
  4 -> 0,
  5 -> 1
)

This is no coincidence. Notice that we partially apply an element to get each row via this anonymous function: (m |+| _). Since each element has an inverse, this function can be inverted: (_ |-| m). So this function is actually a bijective function from a set of elements to itself, which, as we learned in the previous post, is a permutation by definition.

This holds for any group. Its elements correspond to a set of permutations because of the inverse. Furthermore, those permutations have a combining operation that gives them the same group structure (ie., its combination table looks identical). In more formal terms, every group is isomorphic to some permutation group. This fact is known as Cayley’s Theorem.

This is useful because permutations are often simpler to work with in calculations than a naive implementation of a group that they’re isomorphic to. If we have a group, we can implement its data types and operations in terms of permutations. Furthermore, every finite permutation group can be decomposed into a unique product of finite simple groups. These simple groups and their properties are well understood and can help reveal the structure of groups in the problem domain.

Example: Permutations of Three Elements

Let’s look at another concrete example of Cayley’s Theorem. Imagine you have a tile in the shape of an equilateral triangle. Consider the ways you can flip and rotate this tile so that it fits into its original outline. These different orientations of the tile are called the symmetries of a triangle.

These transformations form a group where the combining operation is sequential application of of transformations. For example, you can rotate the triangle clockwise, then flip it 180 degrees across its vertical axis, or you can perform this action in a single flip that switches the top corner with the left. The first two transformations combine to give a third transformation. Note that this operation is not commutative; flipping vertically then rotating, isn’t the same as rotating first then flipping vertically.

All in all, there are six symmetries of a triangle, as shown in this image:

The three corners are labeled so we can reference any of these transformations by reading off the labels from the triangle.

ABC ACB

BCA BAC

CAB CBA

We’ve seen these six words before. These are precisely the six permutations of the string "ABC" that we worked with in our previous post. We can represent our group of symmetries using the permutations we’ve already defined. These permutations themselves form a group under function composition:

implicit object PermGroup extends Group[Perm] {
  def empty = Map(A -> A, B -> B, C -> C)

  def inverse(p: Perm) = p.map(_.swap)

  def combine(p: Perm, r: Perm) = Perm(p.compose(r))
}

Let’s use this group definition to create a combination table analogous to the one we made for Mod6:

val perms = List(abc, acb, bac, bca, cab, cba)

val permsTable = perms.map(m => perms.map(m |+| _))

Our permutations are represented by Map instances that have a large toString, so we’ll simplify our table by instead using the index of each permutation from the above list:

scala> permsTable.map(_.map(perms.indexOf).mkString(" ")) foreach println
0 1 2 3 4 5
1 0 4 5 2 3
2 3 0 1 5 4
3 2 5 4 0 1
4 5 1 0 3 2
5 4 3 2 1 0

We’ve taken two different groups, the integers under addition modulo six, and the symmetries of an equilateral triangle, and found a way to represent them using permutations. The combination table for either shows that each element can be combined with every other element to get any of the six elements. We’ll use this in future posts where we use permutations to translate Rubik’s cube state and algorithms.

Tips for Teaching Scala

2019-06-20T00:00:00Z

I recently gave a talk on teaching Scala. I first gave the talk at the Scala in the City meetup, which was a dry run for the version I gave at Scala Days. Take a look at my slides if this is of interest to you. My talk centered around five tips for teaching. Here I give a quick rundown of the tips and some references for further reading.

Before getting into the tips a bit of context is useful. When programmers discuss how to teach programming the discussion almost always focuses on the choice of programming language. Someone will say Python, someone else will advocate for Javascript, and there will always be someone who is adamant that QBasic is the One True Way because that’s what they learned with. While I think language is important there are two other really important factors that rarely make it into these conversations: curriculum and pedagogy. Curriculum is what you teach and pedagogy is how you teach. I know from my own experience, and from reading the literature, that these two factors can make a huge difference. For this reason my tips focus on curriculum and pedagogy in equal measure. Let’s get on to them.

Notional Machines

My first tip is to teach some kind of “notional machine”, which means a simplified machine model that students can understand programs in terms of. This is most appropriate for beginning learners. The first thought that might come to mind you read this is some kind of von Neumann machine with registers, a stack, and heap. In functional programming the notional machine is much simpler: it’s algebraic substitution. Substitution is very easy to use (my primary school age children can do it) and allows for compositional reasoning. More on notional machines in Programming Paradigms and Beyond.

Programming Strategies

Programming strategies are, as far as I know, something unique to how we at Underscore and Inner Product teach programming. That said, they are heavily inspired by the design recipes in How to Design Programs. The core idea is to allow students to move from problem to solution in a systematic and repeatable way. Programming strategies allow code to written faster with fewer bugs, and by standardizing techniques result in more readable code. They would take many words to explain but the slides give some lengthy examples of the main strategies and my colleague Adam’s slides describe a larger example.

More Than Code

This tip is really a reminder that there is more to programming than writing the code. At least two areas need to be taught as well: debugging and tool use. There is a lot of implicit knowledge here, such as interpretering Scala’s error messages. These areas can be explicitly taught. Software Carpentry, for example, has some lessons on using the shell and Git that are probably very good. However you might not want to take time away from other topics to do this.

Another way to teach them is implicitly, by demonstrating them as part of other lessons. Live coding is a great way to do this! You’re bound to make errors, so you can then demonstrate error recovery and debugging, and you’ll naturally be using your tools as you live code. One pro tip: when you hit an error and your brain freezes that is an excellent opportunity to get the students to solve the error. It makes for a better lesson if they’re engaged with the problem and it gives you a chance to reboot.

Shut Up

This tip is something I had to learn the hard way. People need time to think. They need to grapple with problems and fail before they can succeed. When I was a new teacher I was so keen to help that I’d jump in the moment I saw someone struggling. I was so fast they wouldn’t get a chance to learn. Whenever there was silence—because a student was figuring something out, for example—I’d rush to fill it with words.

I’ve learned to slow down a bit, let students move at their own pace, and when I help I try to ask probing questions (“which strategy are you using here?”, “what do you think is going wrong?”, and so on) rather than addressing the problem directly. It’s an unfortunate truth that we can’t do the learning for the students. The struggle is real and we must let the student experience that for themselves. (Thanks to Anna Shipman for pointing out the error of my ways!)

Peer Learning

My final tip is to encourage students to engage in teaching—teaching and learning are in many ways the same thing! For programming tasks, pair programming or mob programming can work really well. For more general tasks I like to play what I call “the hypothesis game”. The game works like this: the teacher asks a question and gets students to vote on an answer. Students should then turn to the person next to them and explain how they arrived at their answer. Students can vote again, to see if they have changed their mind. Finally they should receive the correct answer and an explanation. By explaining their thoughts the student has to try to make a coherent story, which quickly exposes inconsistencies and errors in their mental model. They are then in an ideal state of mind to receive the correct explanation. When working alone the venerable tool of rubber ducking can be used to simulate an audience.

Further Resources

The above five tips are far from the final word on teaching programming, so I want to throw in a few more resources that have influenced me.

Everything Greg Wilson does is great, but if you only read one thing of his make it Teaching Tech Together. It’s short, to the point, and very good. His paper (with Neil Brown) “Ten Quick Tips for Teaching Programming” is also a good read and, with ten tips, has twice the value of this blog post!
Visible Learning collects the work of John Hattie, particularly his large meta-analyses and rankings of the literature on pedagogical techniques. Although there is some debate on the correctness of his effect size calculations, I believe the overall rankings are in general correct, and they provide for me a very quick way to find the most impactful teaching techniques to study.
The PLT research group provided my first introduction to programming language theory, as distinct from programming, and to teaching programming. I’ve already mentioned How to Design Programs. Program by Design and Bootstrap are other inspirations.

Conclusions

Teaching programming is a distinct skill from programming, and one that I have only just scratched the surface of. I hope the above helps you become a better teacher, whether you’re a senior developer teaching juniors, helping out at a program such as ScalaBridge, or teaching yourself.

Type Classes vs Records of Functions

2019-07-02T00:00:00Z

Type classes and records of functions are two very similar tools that are available in languages like Haskell, Scala, and Rust. Given the similarity the question arises of which we should use. In this blog post I discuss when I think one language mechanism should be preferred over the other.

A Who of What?

Before we get into the details, lets just clear up the terminology. I’m going to assume you know what a type class is. A record is the Haskell term for what in Scala we’d call a class (or trait, or case class) and in Rust a struct. Basically it’s a data structure where the fields (the bits that store the data) have names. So a record of functions is a data structure with named fields where the fields hold functions. In OO parlance fields that hold functions are methods, so we’re basically talking about objects.

An object, or record of functions, is very similar to a type class. In fact if we forget about the compile-time dispatch that type classes bring it’s the same thing. This similarity is why the question arises as to which we should use.

Composition

Type class composition is one nice feature that records of functions don’t provide. The basic idea is that if we define the base elements and the composition rules, the compiler will automatically apply the composition rules to construct a type class instance.

For example, if we have a Monoid type class such as

trait Monoid[A] {
  def combine(x: A, y: A): A
  def identity: A
}

and instances

implicit object intMonoid extends Monoid[Int] {
  def combine(x: Int, y: Int): Int =
    x + y

  val identity: Int = 0
}

implicit def optionMonoid[A](implicit m: Monoid[A]): Monoid[Option[A]] =
  new Monoid[Option[A]] {
    def combine(x: Option[A], y: Option[A]): Option[A] =
      (x, y) match {
        case (Some(x), Some(y)) => Some(m.combine(x, y))
        case (Some(x), None)    => Some(x)
        case (None,    Some(y)) => Some(y)
        case (None,    None)    => None
      }

    val identity: Option[A] = None
  }

we don’t have to explicitly define Monoid[Option[Int]]. The compiler will construct the instance for us. No such automatic composition takes place with records of functions.^[1]

So here is our first criteria for deciding if we should use type classes or records of functions: will type class composition bring us a lot of value? If not, perhaps we shouldn’t use a type class.

Comprehensibility

You’ll sometimes see functional programmers ranting about “lawless type classes”. This combines two of (some) functional programmers favourite things: impenetrable jargon and getting bent out of shape. However, there is some point to this discussion.
Type class “laws” are statement, usually expressed in maths, of some properties that must hold for a type class instance to be considered valid. For example, for Monoid the laws are:

the binary operation must be associative, so combine(x, combine(y, z)) == combine(combine(x, y), z); and
the identity must be a commutative … umm … identity, so combine(a, identity) == a == combine(identity, a).

Defining the semantics is important because it’s these semantics that allow us to implement systems using type classes and know they’ll work as we expect. Let’s address this from two different angles.

One way of seeing the importance of clearly defined semantics is to consider how many possible type class instances we could implement for Monoid if we disregarded the laws. Almost anything would be valid. For example, we could define

implicit object intMonoid extends Monoid[Int] {
  def combine(x: Int, y: Int): Int =
    x * (y - 42)

  val identity: Int = 42
}

or indeed any other combine and identity that match the type signature. If this was common place how would we ever understand what code using type classes will do? Type classes seem fairly magical in the first place. We need laws to allow us to build understanding when they are being used.

As another example, monoids are really useful in data science because they allow us to easily parallelize jobs. Remember associativity says that a + (b + c) == (a + b) + c. If we consider a pair of brackets to be a machine, if the operation we want to perform is a monoid it doesn’t matter how we distribute work across those machines so long as retain the ordering of the data (and if the operation is commutative, which most are, the order doesn’t matter at all). Here the clearly defined semantics allow to guarantee that our distributed system will be correct.

Some type classes don’t have laws. This is what a “lawless type class” is (sadly, not some lovable functional programming rogue that steals from the rich to give to the poor.)

Now, are lawless type classes bad? Not necessarily! Lawlessness (gosh, I hate this pompous terminology) is a proxy for the real issue, which is program understanding. If a type class has laws then you have some principles you can use to reason about your program. A lawless type class might still have principles you can use to reason about code. For example, the 0.9 branch of Doodle has a Renderer type class. Its role is to render (i.e. draw) a picture to some kind of canvas. There aren’t any useful laws you can write about this without introducing a huge amount of mathematical machinery to describe the effect of rendering. However it’s still fairly easy to understand what this type class does.

So here is our second criteria: if we can clearly define the semantics of an interface it could be a type class. If the interface is just a blob of functions that “do stuff”, like we might find inside the implementation of an interpreter, it probably should not be a type class.

Multiple Instances

Type classes use types to choose type class instances. In other words they dispatch on type. Different languages have different rules for where they find type class instances, but in all cases that I know of the compiler will search outside the usual lexical scope for instances. If there are multiple instances for the same type it could be difficult to work out which one is used. Haskell forbids this. Scala allows multiple instances but if two or more are in scope code will not compile. I’m not sure what the situation is with Rust.

Where multiple instances are allowed there are clear rules for which instance is being used, but that doesn’t mean it’s easy for the programmer to work out what the compiler will do. For example, the choice of instance might depend on imports that are far away from the code being viewed, or on complicated priority rules.

This gives us another criteria for choosing between type classes and records of functions: if we could want multiple instances for the same type we’re probably better using records of functions than type classes. This is really another facet of “Comprehensibility” above. Using multiple instances can lead to confusion when we’re relying on the compiler to choose instances for us.

Convenience

The final issue I want to consider is convenience. A library’s API is the user interface through with the programmer interacts with it, and using type classes can make that API easier to use. For example, in Doodle making the Renderer a type class means the user doesn’t have to explicitly specify the Renderer when calling the draw method on a picture. This makes drawing easier. The user needs to know less about the library to get something working.

So my final criteria for choosing between type classes and records of functions: will using type classes make the code easier to use for the end user?

Summary

We’ve seen a few different reasons for choosing between type classes and records of functions. In summary they are:

if automatic composition will be useful then consider type classes;
if semantics are not well defined don’t use a type class;
if multiple instances are likely a type class is probably the wrong choice; and
if it will make your code substantially easier to use a type class might be the right choice.

Hopefully this will make the decision easier for you.

There are some languages and libraries that allow adding and removing fields from records at runtime. They are generally known as “extensible records”. To the best of my knowledge no such system is in widespread use. OO languages allow compile-time composition (usually called extension or inheritance). Neither system allows automatic type-driven composition, which is the magic that type classes bring. ↩︎

Optional Actions

2019-11-18T00:00:00Z

Sometimes, amongst required actions, we need to optionally do something. In this post we’ll see how we can use cats to concisely handle this situation.

The Basic Scenario

Here’s some code that approximates the basic scenario:

for {
  x <- requiredAction()
  y  = if (x.isAmazing) optionalAction()
} yield x

There’s an immediate issue: we don’t have an else for our if.

Did you also know that this is allowed in Scala? An if without an else returns Unit. *Sigh*.

Let’s complete the expression with a placeholder:

for {
  x <- requiredAction()
  y  = if (x.isAmazing) optionalAction()
       else ??? // TODO
} yield x

However, as written, if the optional action is executed, we won’t know if it succeeded or failed. Take a moment to see why…

Avoiding Unexamined Effects

Do you see why the action can fail and we won’t know it? Say the optionalAction returns a Future, then y is assigned that Future. And a Future isn’t the result itself, it merely represents some future value. We need to wait until the Future completes to know if it succeeded or not.

for {
  x <- requiredAction()
  y  = if (x.isAmazing) optionalAction()
       else ???
  // `y` is the action itself, not the successful value of the action!
} yield x

This is true of any monad we use in our expression. If our actions return Either, a value of type Either doesn’t tell us if it suceeded or failed. We need to know if the value is a Left or a Right. And so on for other monads.

For any monad, how do we know if some action succeeded? If it does succeed, we’ll get a value on the left-hand side of the <- in our for-comprehension:

for {
  x <- requiredAction()

  // switch from using `=` (value binding) to `<-` (monadic binding)
  y <- if (x.isAmazing) optionalAction()
       else ???
} yield x

Obligatory reminder: a for-comprehension is just syntactic sugar for
nested flatMap calls. So y <- someAction is really someAction.flatMap(y => ???).

The only way y can have a value is if optionalAction succeeded, or the else clause’s action was successful.

Let’s take care of the else case, when x.isAmazing is false. We need to provide some (monadic) value that has a type compatible with optionalAction, in order for the expression to type check. What’s the type of optionalAction?

Since we want to be monad-agnostic, let’s call the monad F. optionalAction will return an F, and the else branch also needs to return an F. But F is a container type, it holds a value. It doesn’t really matter what our else clause returns, so let’s choose () (“Unit”). We “lift” a Unit into the current monad via pure:

import cats.implicits._ // for extension methods like pure

for {
  x <- requiredAction()
  y <- if (x.isAmazing) optionalAction()
       else ().pure[F] // lift a value into an effect F
} yield x

Do we need y? No! We can “throw it away” by naming it _:

for {
  x <- requiredAction()
  _ <- if (x.isAmazing) optionalAction()
       else ().pure[F]
} yield x

Luckily for us, this “if condition, run the action, else pure Unit” pattern is a helper method named whenA!

import cats.Applicative

for {
  x <- requiredAction()
  _ <- Applicative[F].whenA(x.isAmazing)(optionalAction())
} yield x

NOTE: There is a form of whenA that acts as an extension method on an effect, but the effect is not lazily evaluated, which may be necessary with effects like Future. So please ignore the above ugliness.

To summarize so far:

We need to evaluate optional effects, otherwise we won’t know if they succeeded or failed.
If we have a boolean condition, we can use the whenA combinator to choose between an optional action and an “empty” effect that returns ().

Optional Actions via the `Option` type

There’s an alternate way of encoding optional actions, let’s use the Option type! Instead of checking a Boolean value to conditionally evaluate an action of type F[A], what if the action itself was contained within an Option? Then it’s optional, right?

for {
  x    <- requiredAction()
  optA  = // has type Option[F[Unit]]
    if (x.isAmazing) Some(optionalAction())
    else None
  // TODO: extract result of opt
} yield x

We could use the Option.when factory method to replace the if (predicate) Some(action)/else None code:

for {
  x    <- requiredAction()
  optA  = Option.when(x.isAmazing)(optionalAction())
  // TODO: extract result of opt
} yield x

We have a value of type Option[F[Unit]], but our expression requires actions to be in the F monad. Is there a way to transform an Option of F into an F of Option? Yes! That’s sequence (which is equivalent to traverse):

import cats.implicits._

for {
  x    <- requiredAction()
  optA  = Option.when(x.isAmazing)(optionalAction())
  _    <- optA.sequence // Option[F[Unit]] => F[Option[Unit]]
} yield x

traverse is everywhere!

WARNING: Putting a Future within an Option doesn’t optionally execute the Future, because Future is eagerly scheduled. So you can’t use this technique with Future. Use cats.effect.IO instead.

Conclusions

Optionally performing actions is a common need, and they have a regular structure we can abstract over using cats:

Applicative.whenA lets us construct an optional action from a predicate and a way to construct that action. It’s built from an if/else conditional and using pure to construct an empty action in case the predicate fails.
Traverse.sequence lets us transform an optional action (Option[F[A]]) into an action that produces an optional value (F[Option[A]]), because our for-comprehension is using the F monad, not Option.

At the same time, we need to avoid pitfalls like constructing optional actions without ensuring they are a part of the entire computation. We also showed how we don’t necessarily care about the value produced by an optional action, only that the action succeeded. In a for-comprehension, this means:

evaluating the action with <-; and
naming the result _ (to forget it)

Leveraging Monoids for More Powerful Summarization

2019-12-17T00:00:00Z

During our training and mentoring, we often hear students say “I’m not sure what to do here” when faced with trying to choose what function to call in order to solve their problem. First, it’s completely normal; nobody instantly knows the answer. To try to help, one piece of advice we’ve found to be useful is in the form of a heuristic:

The solution is usually either a map, flatMap, or fold.^*

In this post we’ll be discussing the power of folds: how they are used to summarize a data structure, how summarization can be decomposed and abstracted, and how that abstraction can be leveraged to provide better performance in a generic way.

^*And if it isn’t one of those, it’s probably traverse.

Decomposing Summarization

If a List contains numbers, we can compute the sum of the elements using a fold:

List(1, 2, 3).foldLeft(0)((sum, i) => sum + i)
// res0: Int = 6

foldLeft has a rather generic signature, so let’s factor out the necessary knowledge to summarize our List of Ints:

We need a starting value to initialize our summary, in case the list is empty: ifEmpty: Int; and
We need a way to combine the previous summary to the next element: combine: (Int, Int) => Int.

Let’s write a helper function summarize to name these parts, and just delegate to foldLeft as the implementation:

def summarize(is: List[Int], ifEmpty: Int, combine: (Int, Int) => Int): Int =
  is.foldLeft(ifEmpty)((sum, i) => combine(sum, i))

summarize(List(1, 2, 3), 0, _ + _)
// res1: Int = 6

But how could we summarize any list, not just a list of numbers? Let’s allow the caller to choose the element type, and adjust the ifEmpty and combine helpers:

def summarize2[A](as: List[A], ifEmpty: A, combine: (A, A) => A): A =
  as.foldLeft(ifEmpty)((sum, a) => combine(sum, a))

summarize2[Int](List(1, 2, 3), 0, _ + _)
// res2: Int = 6

Now the caller can summarize a list any way they want. But it’s annoying to have to supply ifEmpty and combine for every call; those parameters will (almost) always be the same for every type A.

Capturing Common Behavior in a Typeclass

Let’s factor those two helpers into a typeclass:

// n.b. exactly the same as cats.Monoid
trait Monoid[A] {
  def empty(): A
  def combine(a1: A, a2: A): A
}

And then implicitly provide the Monoid containing our empty and combine helpers:

def summarize3[A](as: List[A])(implicit M: Monoid[A]): A =
  as.foldLeft(M.empty)((sum, a) => M.combine(sum, a))

Let’s create an Monoid[Int] instance so we can use it in summarize3:

implicit val intMonoid: Monoid[Int] =
  new Monoid[Int] {
    def empty(): Int = 0
    def combine(i1: Int, d2: Int): Int = i1 + d2
  }

Finally we’re back where we started:

summarize3(List(1, 2, 3))
// res3: Int = 6

summarize3 will now work for lists of any type A, as long as A has a Monoid[A].

Deriving `foldMap`

But what if we have a list of some type that doesn’t, or can’t, have a Monoid? To compute a summary for it, we’ll need to transform our list into a type that does have a Monoid. Is there a way to do this?

There is, and it’s a common strategy in functional programming: we ask for help from the caller, since foldMap itself can’t know what to do. If the caller provides us with a function A => B, and B has a Monoid, then we can summarize. Aha!

This function is usually called foldMap, because we’re both fold-ing (the list) and map-ping the elements (the A => B function):

// Summarize a List[A] as a B, if B has a Monoid.
def foldMap[A, B](as: List[A])(f: A => B)(implicit M: Monoid[B]): B =
  as.foldLeft(M.empty)((b, a) => M.combine(b, f(a)))

If A already has a Monoid, then we can summarize using foldMap by not transforming the data. That is, we transform it with the identity function:

def sum[A: Monoid](as: List[A]): A =
  foldMap(as)(identity)

sum(List(1, 2, 3, 4, 5))
// res4: Int = 15

It’s not very exciting, but we can count the length of a list too (implicitly using the Monoid[Int] to “increment”):

def count[A](as: List[A]): Int =
  foldMap(as)(_ => 1)
  //               ^
  //               increment count by 1
  //               for each element

count(List(1, 2, 3, 4, 5))
// res5: Int = 5

Computing the Mean with `foldMap`

What can you do with the sum and the count of a list? Compute the mean!

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

sum(l)
// res6: Int = 15
count(l)
// res7: Int = 5

def mean(is: List[Int]): Double =
  sum(is).toDouble / count(is)

mean(l)
// res8: Double = 3.0

It works!

Computing the Mean with `foldMap`: Improved!

For the performance-minded, there’s an issue with the computation of the mean: it processes the list twice, once for the sum and once for the count. Could we compute the mean in only one pass?

One way to think about how we could do this would be to fill in, as best we can, the parameters to one call to foldMap, in order to compute the answer we’re looking for. That is, we need foldMap to return the sum AND the count:

def onePassMean(is: List[Int]): Double = {
  // need sum AND count from foldMap
  val (sum, count) =
    foldMap(is)(i => ???)
  
  sum.toDouble / count
}

If foldMap is to return an (Int, Int) tuple, the A => B mapping function–the ??? above–needs to return (Int, Int), and foldMap also requires a Monoid[(Int, Int)]

def onePassMean(is: List[Int]): Double = {
  val (sum: Int, count: Int) =
    foldMap(is)(i => (???): (Int, Int))
    //                ^
    //                needs to produce (Int, Int)
  
  sum.toDouble / count
}
// error: could not find implicit value for parameter M: repl.Session.App.Monoid[(Int, Int)]
//     foldMap(is)(i => (???): (Int, Int))
//     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

We know the values of components of the tuple: the first needs to be the sum and the second needs to be the count. When foldMap uses the Monoid[(Int, Int)] to combine tuples, it needs to work like this:

val sumAndCount = (10, 4)
// sumAndCount: (Int, Int) = (10, 4)
                 // ^  ^
                 // ^  previous count
                 // previous sum
val toAdd = (5, 1)
// toAdd: (Int, Int) = (5, 1)
          // ^  ^
          // ^  increment the count by 1 
          // increment the sum by 5
val totals = (10 + 5, 4 + 1)
// totals: (Int, Int) = (15, 5)

This generalizes to any tuple: combining two tuples produces one tuple with combined components. Sounds familiar? Here’s the Monoid we need! (if there exists a Monoid for the each component of the tuple)

implicit def tuple2Monoid[A, B](implicit MA: Monoid[A], MB: Monoid[B]): Monoid[(A, B)] =
  new Monoid[(A, B)] {
    // the empty tuple is a tuple of empty values from each Monoid
    def empty(): (A, B) = (MA.empty, MB.empty)

    // combine A fields via MA, combine B fields via MB
    def combine(ab1: (A, B), ab2: (A, B)): (A, B) =
      (ab1, ab2) match {
        case ((a1, b1), (a2, b2)) =>
          (MA.combine(a1, a2), MB.combine(b1, b2))
      }
  }

tuple2Monoid.combine((10, 4), (5, 1))
// res11: (Int, Int) = (15, 5)

Now we can compute our mean with one pass over the data:

def onePassMean(is: List[Int]): Double = {
  val (sum, count) =
    foldMap(is)(i => (i, 1))
    //                ^  ^
    //                ^  increment count by 1
    //                increment sum by i
  sum.toDouble / count
}

onePassMean(l)
// res12: Double = 3.0

Summary

Summarizing a List is a fold.
The initial value and combining operation of elements for a summary can be abstracted over by a Monoid.
foldMap summarizes a List by requiring each element be able to be transformed into something that has a Monoid. foldMap is available in cats as part of the Foldable typeclass, which models foldable (“summarizable”) types like List.
We can derive a typeclass instance for tuples of monoids, which then gives us a way to combine values “in parallel”. Typeclass instances for tuples are included in cats, and are usually imported into scope via the wildcard import cats.implicits._.

// The same example as above, but using cats.
import cats.implicits._

List(1, 2, 3, 4, 5).foldMap(i => (i, 1))
// res13: (Int, Int) = (15, 5)

Inner Product's Best of 2019

2019-12-31T00:00:00Z

Here’s a sample of the best writing, talks, and people we’ve come across in 2019. We hope you enjoy them as much as we did.

– Adam, Mark, Noel, and Stewart

Talks

Many of our favorite talks took place at Strange Loop, but sadly none of us could attend. For all the conferences that make their talks accessible to the public, thank you!

Intro to Cats-Effect, Gavin Bisesi

Adam: Gavin provides a thorough and illuminating tour of cats-effect for any Scala developer.

Performance Matters, Emery Berger

Mark: While I spend a lot of time ignoring performance in order to model correct and reasonable code, performance can not be ignored forever. Making changes to improve performance can have surprising consequences. Everybody should watch this talk before making performance enhancements. It is far more than Stabilizer. The lessons learned go beyond any particular language.

Scale By The Bay 2019: Paul Cleary, Re-programming the programmer, from Actors to FP, Paul Cleary

Adam: Paul shares the real story of how he and his team redesigned and refactored a system to use the Typelevel ecosystem of libraries. It’s not just a technical story, it’s a story of the process the team went through to mentally switch gears to a more principled and functional approach.

Probabilistic scripts for automating common-sense tasks, Alexander Lew

Mark: An accessible and practical talk about using probabilistic scripts for automation. It describes common challenges and how to address them. It does this in a useful way.

Finding bugs without running or even looking at code, Jay Parlar

Mark: This talk is fascinating. The only thing better than eliminating defects at compile time is before writing any code at all! Jay describes compelling examples from his experience that really motivate Alloy, TLA+, and the ideas in general.

Videos

The “real programmer” myth, Maciek Gorywoda

Adam: A brilliant exposition of one of the worst parts of our (programming) culture.

NaN Gates and Flip FLOPS, Tom 7

Adam: If you ever feel like you’re too big of a nerd, then this video will let you know that you’re fine, really, you’re just fine. It’s also hilarious.

Writing

Parse, don’t validate, Alexis King

Definitely our favorite post of the year.

Noel: This blog post clearly articulates a concept I feel is at the core of effectively using types. It gives a name to something I have unconciously understood but have never been able to so plainly and concisely communicate.

We attempted a similar subject at ScalaDays Berlin 2018 entitled “Strings are Evil”, inspired by Changlin Li’s 2018 NEScala talk “Moving Beyond Defensive Programming”, but Alexis’ post has the best exposition.

Yes! and …, Tom Critchlow

Noel: “[F]or knowledge work, the performance of the work is the work” is the line in “Yes! and…”, a blog post inspired by a book, that told me I needed to pay attention to this. This strongly resonates with my expererience. It’s not enough to do the work; the work must be seen to have value. The ideas in this post, and its follow ups, are particularly relevant for consultants but apply for anyone who works in any but the smallest organizations.

Using a hard disk as a listening device, Andrew Kwong, Wenyuan Xu, and Kevin Fu

Mark: It is fun to see how people can use things in unexpected ways.

Other Recommendations

ScalaBridge London

Noel: “Best of” lists often imply passive media consumption, so I wanted to add something that has definitely required active engagement this year. ScalaBridge London aims to increase diversity within the (London) Scala community. Our main way of addressing this is by teaching Scala. We’ve been running for about a year and at least two of our students have been hired as Scala developers in that time. Being involved with ScalaBridge London for me has been a great experience on so many levels. It’s enabled me to get further into teaching and start dipping my toe in sociology, it’s some of the most meaningful work I do, and it’s just plain fun to hang out with fun people.

LSE Podcasts

Noel: I’m unclear how I ever did housework without podcasts. I listen to a lot of podcasts but those from the LSE are the ones that I think about the most. There is fantastic stuff here that helps me better understand the world and myself.

The Unison language

Mark: It has some exciting innovations. Can’t wait to really try this. Watch the videos. Here is one from Strange Loop 2019 but there are others that are good also. Search Youtube.

Creative Coding

Noel: One of the themes of my year was creative coding. Although there are a lot of resources for creative coding I’m not a fan of the imperative approach the majority take, which I think obscures the essential ideas. Instead I’ll link to three books that address the intersection of maths and art in different ways: Creating Symmetry, The Seduction of Curves, and Mathematics and Art: A Cultural History (notably all published by Princeton Press). I got Creating Symmetry a few years back but this is the year when I spent the most time with it.

Turtles in Minecraft

Mark: These turtles are little robots with a programmable, on-board computer. They can be programmed to perform necessary but tedious work so the player can focus on other activities. The turtles use Lua for reasons I have yet to determine. I think mining and other turtles might be good motivation for learning programming. Hopefully my son and I can dig into this, so to speak, when he returns this summer. These are not from 2019, but I just learned about them this year.

For all the Family

Noel: The Turing Tumble is elegant and accessible. Noelle Stevenson doesn’t just have a great name but tells great stories in comics and cartoons.

Building Serverless Scala Services with GraalVM

2020-02-06T00:00:00Z

A recent project has involved serverless web services in Scala, which led me to investigate using GraalVM’s Native Image tool to create native executables. In this blog post I describe the steps necessary to build a native executable from a simple http4s web service. There is also complete code accompanying this example.

Why Native Image?

Before going into the details it’s worth going over a bit of background. GraalVM is a new Java virtual machine and associated tools that brings increased performance compared to the older Hotspot VM. Native Image is one of the most interesting tools that comes with GraalVM. It compiles JVM bytecode into native executables. This promises reduced startup time and decreased memory consumption compared to running on a full JVM. This is particularly attractive for serverless computing as startup time is an issue and billing often increases with memory consumption.

Overview of the Process

Building an executable with Native Image is not hard but there is a bit of setup involved the first time. The main steps are:

Install GraalVM locally (this is optional, but it is faster to test this way);
Writing code (the fun part!);
one-off configuration so that GraalVM can handle uses of reflection and Unsafe;
creating a Docker image to build the executable (optional if you are developing on the same platform you’re deploying to); and
creating a Docker image to deploy the executable (again, optional).

Let’s look at each in turn.

Installing GraalVM

Installing GraalVM is our local computer is optional (if we go the Docker route, as we do later in this post) but advised as it is much faster to test things locally before invoking Docker. The part of GraalVM we’re interested in, Native Image, is an addon to the main distribution. You need to install GraalVM first and then use the tool it provides to add Native Image. I used sdkman to install GraalVM, so I can run it alongside Hotspot (I need to continue to use Java 8 to build libraries I maintain.)

With sdkman installed the magic to install GraalVM is

# Show available JVMs
sdk list java
# Install GraalVM 19.3.1 running on JDK 11
sdk install java 19.3.1.r11-grl

Once you have GraalVM adding Native Image is just a matter of running

gu install native-image

Test everything is installed by running native-image --version. You should see output similar to GraalVM Version 19.3.1 CE.

Writing the Code

The next step is to write the code that we’ll compile to a native executable. For my case I wrote a very simple web service using http4s and Scala 2.13.

From this code we want to generate a JAR file that Native Image will then compile to an executable. In my case I used the sbt-assembly sbt plugin to generate a single fat JAR. Running the assembly task in sbt produces a single JAR that I can pass to Native Image with the following command:

native-image --verbose -jar target/scala-2.13/http4s-native-image-assembly-0.1.0-SNAPSHOT.jar ping-server

The --verbose flag is not strictly needed but I found it useful for debugging. If you try this using my code it should just work and produce an executable. If you try on your own code, however, you will likely run into some errors because Native Image does not support all the features of the JVM. In the next section I discuss the problems I encoutered and how I fixed them.

GraalVM Configuration

This step is perhaps the most important. Native Image has various limitations which we must work around. The lack of reflection is likely to be an issue for any sizable application. Scala code does not make much use of reflection. Unfortunately we often rely on Java infrastructure that does use reflection. This is the case for http4s, which relys on a Java logging library that uses reflection. For Scala 2.13 there is also an issue with its use of Unsafe.

To use reflection with Native Image we must tell Native Image ahead of time which classes will be reflected so it can generate the appropriate data. There are various ways to do this but the most modular is to create files called reflect-config.json in src/main/resources/META-INF/native-image/package-name/project-name replacing package-name and project-name with appropriate names. This is my example. The format is reasonably self explanatory. If we do this we can package our configuration with our code and Native Image will automatically find it. Otherwise we must provide additional command line arguments telling Native Image where to find our configuration.

We can configure other Native Image settings by creating a file called native-image.properties in the same location. This is important to get Scala 2.13 working with Native Image. Scala 2.13 has some uses of Unsafe, encapsulated in scala.runtime.Statics, that Native Image does not recognise and hence cannot compile. To get around this create a file src/main/resources/META-INF/native-image/org.scala-lang/scala-lang/native-image.properties containing

Args = --initialize-at-build-time=scala.runtime.Statics$VM

This initializes the object scala.runtime.Statics at compile-time and copies the object into the native executable’s heap, getting around the problem.

We can set other Native Image commands this way, which again allows for an encapsulated and modular build. Here’s what I set for co.innerproduct/ping, which applies to the code I created.

Args = -H:+ReportExceptionStackTraces --allow-incomplete-classpath --no-fallback

These parameters, in order, are used to:

report more informative traces in case of errors;
allow compilation of code that does not contain all classes that are referenced in the code, which is important for uses of reflection; and
fail the build instead of generating fallback code when Native Image cannot resolve uses of reflection or other issues.

More information can be in the Native Image documentation and if you use code that makes heavy use of reflection you might want to use the Native Image agent to automatically generate your configuration.

A final issue I ran into was a complaint about Janino. I don’t understand what is causing this but adding Janino as a dependency to my project (and hence including it in my fat JAR) solved the issue.

With all the above in place the code should compile and, several hundreds of thousands of milliseconds later, we’ll have a owkring executable. In my case I can connect to port 8080 with my web browser and see the server is indeed working.

Cross-Building Using Docker

I’m building on a Mac laptop but I want to deploy on Linux. Native Image does not support cross-building, so to build a Linux executable I must run Native Image within a Docker container.

Oracle provides Docker images with GraalVM, but not with Native Image. It’s a simple matter to create an image with Native Image using the Oracle images as a base. Here’s the Dockerfile

ARG GRAAL_VERSION=19.3.1-java11
FROM oracle/graalvm-ce:${GRAAL_VERSION}
WORKDIR /opt/native-image
RUN gu install native-image
ENTRYPOINT ["native-image"]

I can build this image using the command, from within the directory that contains the Dockerfile (which is docker in my code; this directory contains nothing else to keep the resulting image as small as possible.)

docker build -t inner-product/graalvm-native-image .

Now I can use the image I just made to cross-build a Linux executable. I created a sbt task to do this, so that my task could depend on the local of the fat JAR built by sbt-assembly. Here’s the code for this task

lazy val nativeImage =
  taskKey[File]("Build a standalone executable using GraalVM Native Image")

nativeImage := {
  import sbt.Keys.streams
  val assemblyFatJar = assembly.value
  val assemblyFatJarPath = assemblyFatJar.getParent()
  val assemblyFatJarName = assemblyFatJar.getName()
  val outputPath = (baseDirectory.value / "out").getAbsolutePath()
  val outputName = "ping-server"
  val nativeImageDocker = "inner-product/graalvm-native-image"

  val cmd = s"""docker run
     | --volume ${assemblyFatJarPath}:/opt/assembly
     | --volume ${outputPath}:/opt/native-image
     | ${nativeImageDocker}
     | --static
     | -jar /opt/assembly/${assemblyFatJarName}
     | ${outputName}""".stripMargin.filter(_ != '\n')

  val log = streams.value.log
  log.info(s"Building native image from ${assemblyFatJarName}")
  log.debug(cmd)
  val result = (cmd.!(log))

  if (result == 0) file(s"${outputPath}/${outputName}")
  else {
    log.error(s"Native image command failed:\n ${cmd}")
    throw new Exception("Native image command failed")
  }
}

Now I can simply run the nativeImage task from within sbt and, after a substantial pause, I will have a Linux executable called ping.

There’s really only one thing to note about this command: I passed the --static parameter to Native Image. This creates a statically linked executable that has no dependencies on external libraries. This can be important when deploying as discussed in the next section.

Creating a Deployment Docker Image

The final step is to create a Docker image in which I can deploy my code. Because I built a statically linked executable I don’t need very much external support, so I can create a very small image. Alpine Linux is a distribution created specifically for the use case of building small Docker images. I can create my Docker image using Alpine Linux and the executable I built earlier with the following Dockerfile.

FROM alpine:3.11.3
COPY ping-server /opt/ping-server/ping-server
RUN chmod +x /opt/ping-server/ping-server
EXPOSE 8080
ENTRYPOINT ["/opt/ping-server/ping-server"]

We build this image with the following command, assuming the Dockerfile is in the current directory which also contains the executable we previously built.

docker build -t inner-product/ping-server .

We can run the resulting image with using the docker run command.

docker run -d -p 8080:8080/tcp inner-product/ping-server

Now visit http://localhost:8080/ping/hello and you should see a result!

Finally stop the Docker using the container id printed when you ran it above.

docker stop <container-id>

Conclusions

We’ve seen that creating an executable from Scala code using GraalVM Native Image is quite straightforward. There is a bit of one-off cost to get everything setup, but you can copy the work I’ve done and, if you’re just using http4s and other Typelevel projects, it is unlikely you’ll have to do additional configuration. Compilation is not fast, but this is something you could offload to a CI/CD server. The resulting executable is easy to deploy.

One of the attractions of native executables is faster startup and reduced memory consumption compared to the standard JVM. This, along with deployment, is something I’ll look at in the next in this series.

Acknowledgements

I relied on lots of different resources to get this all working. I’ve linked to documentation above where it is relevant but there were a few other sources I used:

This Scala bug report contained the solution to getting Scala 2.13 working with GraalVM Native Image.
This blog post from SoftwareMill was a useful reference for the Docker part of the puzzle.

Thanks Dale and Adam!

Benchmarking Web Services using GraalVM Native Image

2020-02-17T00:00:00Z

In a previous post I discussed the steps needed to compile a http4s web service to an executable with GraalVM Native Image. It’s natural to ask what tradeoffs are made by going this route instead of using the JVM. In this post I present several benchmark results I obtained comparing the Native Image executable to the running on the JVM. Read on to find out which comes out on top!

My goal was to compare executables created with GraalVM Native Image with the same code running on the Java 11 JVM with the GraalVM JIT compiler enabled.

Before we benchmark we need to decide what we are measuring. The nature of the application determines the performance goal we should optimize for. Two main cases arise in serverless computing:

infrequently called services, which prioritize startup time and memory consumption; and
frequently called services, which prioritize long-term performance.

I investigated both cases.

A quick note about my results. My benchmarking environment (also known as my laptop) doesn’t allow me to control for many sources of noise that can affect performance measurements. As a result only large performance differences should be considered valid; small differences might be due to factors I didn’t control for. I haven’t run any statistical tests on my data, partly because I wasn’t able to collect suitable data in some cases and partly because I wasn’t interested in the small differences I would need statistical tests to confirm.

Overview

My main results are:

Native Image has orders of magnitude faster startup time and lower memory consumption than the JVM;
a warmed up JVM has faster response time than Native Image except in the tails, where the JVM response time is much higher.

I also have some additional results from further experiments I ran.

It seems the 10000 requests is sufficient to warm up the JVM for peak performance.
The tail response times of the JVM seemed to really get out of hand on some runs. I’m not sure what caused this. My guess is garbage collection pauses, or perhaps interference from something else on my system, but I haven’t investigated. Native Image responses in the tail seemed to be much more stable.
Attempting very simple tuning of the JVM didn’t yield noticable results.

Startup Time and Memory Consumption

Startup time is one of the most important benchmarks for serverless endpoints that are called infrequently. An infrequently used endpoint will not be already running, so the user must wait for it to start before they will receive a response. It is well established that response time is inversely correlated with user satisfaction so we must care about this for any system that interacts with users.

Memory consumption is another major consideration as all major cloud providers also charge for RAM, usually in 256MB chunks.

To investigate these issues ran an experiment that:

started a server using the Native Image and the JVM;
measured the time it took for the server to respond to its first HTTP request; and
measured memory consumption (resident set size) after this response.

I repeated this process 100 times for each of Native Image and the JVM. The complete process is given by this shell script (this is reproducible research!) Here’s a graph of time to first response.

Here’s memory consumption after the first response.

I’m not confident that my experimental setup will be able to distinguish millisecond differences but this doesn’t matter because Native Image is orders of magnitude faster to start and uses orders of magnitude less memory than the JVM.

Response Time Under Sustained Load

Native Image is faster at starting up, but what about response times under load? I expected the JVM would eventually outperform Native Image if the JIT compiler was given enough data to work with. To test this I used the ab load testing tool to send requests to each server. I sent requests in batches of 10000 with a maximum concurrency of 50. The full experimental setup is given in this script. The graph below shows the zero to 99-percentile response times for Native Image, the cold JVM (the first 10000 requests) and a warm JVM (after 70000 requests).

This graph shows the 95 to 100-percentile respone times for the same setup.

There are a few conclusions I draw from these results:

Native Image continues to outperform the JVM until the JVM is warm;
a warm JVM has a modest response time improvement over Native Image; except
the tail response times (roughly 99th-percentile) for the JVM are much worse than Native Image.

In summary Native Image has much more stable performance than the JVM. It’s performance from start is better and it is less affected by large pauses in the tail of the response time distribution.

JVM Performance Over Time and JVM Tuning

The results from the previous experiment intrigued me. I decided to investigate two questions:

How many requests does it take to warm up the JVM?
Can I improve the tail performance of the JVM with some simple tuning?

To answer the first question I recorded percentile response times using ab with the same setup as before, but this time for each block of 10000 requests from the start to 80000 total requests. The results are graphed below. I only graphed up to the 95th percentile response time as I didn’t want the tails to obscure the rest of the data.

The results show no large performance increase after 10000 requests. I feel confident that the JVM is warmed up after the first batch of 10000 requests, but I don’t know if I could use fewer requests to achieve the same result. I considered investigating this but decided this was going too far from what I set out to do. It only takes a few seconds to warm up the JVM with my current setup so this isn’t a big issue for me.

To answer the second questions I tried two different things:

setting a 200ms pause time goal for the G1GC garbage collector; and
changing some compiler settings that Chris Thalinger used to optimize GraalVM services in his ScalaDays talk.

Complete settings are given in the shell script.

Here are the results.

Although there appears to be a small difference in response time between the various JVM settings I don’t think my experimental setup is sensitive enough to reliably pick up these small effects.

Conclusions and Open Questions

Let’s have a quick recap. The result that is best supported by the evidence is that the executables created by GraalVM Native Image start up much faster and use much less memory than the JVM. My experiments have also shown that Native Image has faster responses time than a cold JVM but a warm JVM has faster response times than Native Image, except above the 98th percentile. My conclusion is that Native Image executables are preferred over the JVM for serverless applications, particularly those where startup time is important or they are IO-bound not CPU-bound.

I also showed that 10000 requests are sufficient to warm up the JVM in my case, but I wasn’t able to show any improvements from simple tuning of the JVM.

There are several open questions. I’m most curious about what is causing the long tail response times I saw on the JVM. The JVM provides plenty of tools to investgate this. My suspicion is it is garbage collection pauses. Using the -XX:+PrintGC flag would be a simple way to investigate this hypothesis. Improving the pause times, assuming it is GC, is more challenging. My first step here would be trying the ZGC garbage collector, which is designed to produce pause times less than 10ms. ZGC is not currently available for MacOS, but is available on Linux.

It is an open question how far my results generalize to other applications. I am reasonably confident that short-lived web services—the typical serverless application—will behave in a similar way to my benchmarks. My expectation is that CPU-bound tasks will benefit from additional optimizations in the JVM and that memory-intensive applications will benefit from the more advanced garbage collectors the JVM brings.

Finally, everything I’ve done—the code, the experiments, and the analysis—is available in the repository so you can try my experiments with your code or machines. Let me know if you do! I’m very curious to hear how the results translate to different domains.

A Sketch of Research on Teaching Programming

2020-03-13T00:00:00Z

In preparation for a talk at NEScala I wrote this quick survey on the research on curriculum and pedagogy for teaching programming (curriculum means what we teach, and pedagogy is how we teach it). My goals are:

give a framework for thinking about curriculum and pedagogy;
give some specific tips for teaching programming;
point out where I believe more research is needed.

My survey is based on the published literature, but it’s not a comprehensive document. I’m not an academic and I don’t have the time (sadly) to read all the relevant literature. However I’ve linked to papers I found interesting or important so you can explore further if something grabs your interest. There is a lot of interesting research out there and the tiny bit I’ve read has made my teaching much better.

What Do We Know About Teaching?

We know a lot about teaching, which has been studied for a very long time. To handle this vast literature we can turn to literature surveys. Perhaps the largest surveys are those by John Hattie which aggregates some 1200 meta-surveys which in total aggregate results over some 300 million students. Hattie ranks different techniques according to effect size. There have been various criticisms of Hattie’s rankings but I don’t believe these criticisms effect the general results, so by looking at the higher ranked methods we can get some good ideas as to effective techniques.

Here are the top ten techniques according to the 2018 survey:

Collective teacher efficacy
Self-reported grades
Teacher estimates of achievement
Cognitive task analysis
Response to intervention
Piagetian programs
Jigsaw method
Conceptual change programs
Prior ability
Strategy to integrate with prior knowledge

There are 122 techniques with effect size at or higher than the average effect size of 0.4. Two questions come to my mind from looking over the list:

Which specific techniques have high effect size and are applicable to teaching programming in my context?
What are the general priniciples behind the effective techniques?

We’ll get onto the second question in a bit, when we look at techniques specific to teaching programming. For now let’s look at what effective methods have in common. I see a few broad themes:

Explicating and correcting students’ knowledge (e.g. #8 Conceptual change programs, #18 Summarization, any technique using discussion). It’s clear that for learning to take place students need to actively engage with their knowledge. This could be writing notes, completing formative assessment, or writing programs. It’s my experience (and I’m sure the experience of many teachers) that students will believe they know something after you have explained it to them but when they come to actually use their knowledge they discover many holes in it. Anything that requires students to engage with their knowledge will show these holes and give them the opportunity to fix them.
Learning with other students (e.g. #7 Jigsaw method, #15 Classroom discussion, #27 Reciprocal teaching). There are many effective strategies that involve learning with other students. It’s possible that the effectiveness of these methods isn’t due to the social aspect, but because discussion and so on forces them to actively engage with their knowledge, but I believe learning with a social component is more effective than learning alone.
Explicit learning strategies (meta-cognition; e.g. #4 Cognitive task analysis, #14 Transfer strategies, #17 Deliberate practice). There is a lot of implicit knowledge in programming, as in other domains. For example, strategies for moving from problem statement to working code is usually left implicit. Making this knowledge explicit seems to help learning.

Now we’ve seen some general principles let’s look specifically at programming.

What Do We Know About Teaching Programming?

We know a lot less about teaching programming than we do about teaching in general, but we still know a fair bit! The general result seems to be that what we know about learning and teaching transfers to programming. For example:

Peer learning (learning with other students) in various forms works well. There are many different approaches. Some examples include:
- Pair programming. This is a good practice to use: students get some exposure to a way of working they may encounter in industry, and mentors may already be experienced in pair programming and hence less training is required.
- Peer instruction is a structured method of discussion suitable for teaching that predominately uses lectures.
- Structured peer learning is a techinque that uses students teachers.
There are many techniques for explicating knowledge in programming. Programming assigments are perhaps the most obvious way to do this, but there are other techniques. We can ask students to trace through programs (e.g. tracing recursion) or ask them to solve “Parsons problems”. All of these methods help students to develop a mental model of how programs work (a so-called “notional machine” that describes some abstract machine that executes the code). Working away from code allows the exercises to focus on particular issues that may be obscured by code, particularly when students are not yet proficient with the syntax.
Programming strategies and design recipes are examples of explicit learning strategies. Giving students explicit strategies allows them to reason about program construction and this seems to be helpful. However this is a fairly new area of study and I think there is much more that can be done here.

There are a lot of choices we can make about a curriculum. Usually the choices are dictated in some part by what is needed to get a job (in a bootcamp) or to support later courses (in a University). We have a bit more freedom at ScalaBridge London so what I’ve done is basically walking the line between what I find fun and what I think is best for the students. Briefly:

We teach functional programming. Substitution is our computing model of choice.
We focus mostly on problem solving and Scala language features. We teach the FP subset of Scala except implicits, and strategies such as structural recursion. We have much less emphasis on producing large systems and preparing students for employment. This is perhaps not a good thing, given most of our students are interested in jobs as programmers.

One feature of our curriculum is introducing programming by creating pictures. This approach is known as “media computation” (see, for example, this paper and this paper) in the literature. The evidence suggests this helps increase diversity. Our students certainly seem to find it enjoyable.

Finally, we should note there is much more to programming than just programming. For example, there is tool use (git, editor or IDE, and so on), workflow, debugging, testing, and so on. We don’t teach this explicitly. Our approach is to teach parts of this implicitly by having experienced developers work with small groups of students. Some parts (e.g. testing) we don’t teach at all.

Bootcamps also offer interview training. Possibly we should do the same.

What Holes Are There in Our Knowledge?

In my opinion there are several gaps:

We don’t know enough about teaching and learning functional programming.
We don’t know much about post-college learners, such as bootcamp or ScalaBridge attendees, though the research literature is growing.

I have two beliefs about functional programing:

it has a much simpler model than alternatives; and
it is amenable to systematic program construction.

Substitution (more formally, “the substitution model of evaluation”) is how we reason about functional programs. It is simple to use—we learned how to do this in grade school—and this same simplicity is why experienced FP developers like using it. The same simplicity applies to learning FP. The model is easy to work with, and a minimal FP language (something like Scheme, for example) can be very small.

Functional programming has an underlying mathematical model that makes it, for example, possible to generate code from type declarations. These same strategies can be used by humans to generate code, and you are a (typed) functional programmer you have possibly had the experience where the code just about writes itself once the types are in place. We can (and do!) teach these strategies explicitly, drawing inspiration from How to Design Programs. There are other strategies (e.g. the connection between free structures and Church encodings) that are outside the scope of ScalaBridge but we found important in our commercial work.

Finally we don’t know much about the needs of the people who attend ScalaBridge. My suspicion is that ScalaBridge attendees are very similar to bootcamp attendees, which suggests that we should consider doing some of the things that bootcamps do (interview preparation and portfolio development, for example.)

References

As well as the references embedded in the post there are a few papers that I found to be good overviews:

Programming Paradigms and Beyond is a nice overview of the concept of a notional machine, how it is useful for teaching, and raises some open issues in programming education.
Computing Education: An Overview of Research in the Field is a recent (2016) paper that does exactly what the title claims, with a focus on high school education.

Finally, if you are interested in exploring the literature here a few tips. Firstly, the computer science education field is pretty terrible in general about releasing their papers in an open way. Most of them are locked behind various paywalls. There are two strategies to combat this: searching the wonderful world wide web for a PDF in the wild or contacting the authors directly. Most academics will be delighted (and somewhat shocked) to have interest in their research and will happily send you a PDF. Google Scholar is the best search engine I know of for papers. It will also link you to papers that cite the papers you’re looking at, and the citations from the current paper. This is a great way to quickly explore the literature.

Thoughts on Recent Online-Only Conferences

2020-05-05T00:00:00Z

Noel and I recently spoke at the Northeast Scala Symposium 2020 (a.k.a. NEScala) and Scala Love conferences. What was unusual for us, as both speakers and attendees, was that both these conferences were online-only!

I’d like to share our thoughts on what worked and didn’t, and what didn’t seem to change at all in this new remote world.

March: Northeast Scala Symposium 2020

The Northeast Scala Symposium 2020 was to be hosted in New York City from March 12-14, and consists of three days of single-track conferences: the Typelevel Summit, the main NESCala conference, and finally the NEScala unconference. In addition, Inner Product was a Gold Sponsor, our first time sponsoring a conference. Why do I say “was to be hosted”? Two days before the conference was set to begin the organizers made the decision that the conference had to convert to online-only, as the coronavirus had started to explode in the United States. I can’t imagine the stress the organizers felt.

tl;dr: NE Scala is still on, but we’re going online-only. 1/6
— Northeast Scala Symposium (@nescalas) March 10, 2020

At first, I was upset, since I was scheduled to fly from Seattle to New York the next day and now had to cancel my flight and hotel. But in hindsight, their decision was wise.

Thursday’s track, the Typelevel Summit, came quickly, and the organizers had a plan. Luckily for me I could immediately be a canary, as I had the first talk! (You Didn’t Know It, but You Really Want to Learn Sequent Calculus: video, slides)

The talks proceded in Zoom, with questions arriving for speakers via the Zoom Q&A panel, Zoom chat itself, and sometimes in the conference Slack channels. As a sponsor, I especially liked the custom background image supplied by NEScala that speakers were encouraged to display:

Speaker view with sponsors background during NEScala. Image stolen from Ryan Williams's NEScala post-mortem.

Ryan Williams’ post-mortem goes into great detail about running the conference. I encourage anyone interested in more effective conferences to take a look.

On a sad note, I didn’t attend the Unconference on day 3. I was too tired!

Of the many talks, these stood out for me:

implicit def bias = stereotypes |+| prejudices, Jeferson David Ossa (video, slides)
- An important break-down of our conscious and unconscious biases, and what we can do about it.
1000+ Compile-time Errors Later and Running Smoothly in Prod, Kevin Meredith (video, slides)
- A quick ten-minute summary of an upgrade gone right, benefitting from the solid foundations of static typing and great Typelevel libraries.
Streams: Your New Favorite Primitive, Ryan Peters (slides)
- A superb introduction to streams from a first-time speaker.
Comonads and the Game of Life, Rebecca Mark (slides)
- Poetics! Automatons! Comonads! This talk has everything, including hidden jokes in the diagrams. A must see!
Bringing Scala to a Diverse Group of Students, Elissavet Velli, Noel Welsh, and Yifan Xing
- A three-person panel about Elissavet’s and Yifan’s path into Scala, with moderation and thoughts by Noel. Real talk, no platitudes. Repeated at Scala Love a month later!
Understanding Scala’s Type System, Bill Venners (slides)
- Great explanations and diagrams.
Scala eDSLs for Domain-Specific Business Logic, Eleftherios “Lef” Ioannidis (slides)
- The first talk I’ve seen that was live-coding in a notebook!

April: Scala Love

For me, Scala Love appeared out of nowhere. I saw the CFP (Call For Proposals) a while ago, then promptly forgot about it until the selected speakers started being announced. What a line up! Everybody was speaking, from Martin Odersky, to Scala old-timers, to Scala newcomers, to first-time speakers. It had two main tracks, and then added an extra track, curated and staffed by JetBrains. In a facinating innovation that I hadn’t seen before, it was a mixed time zone conference to accomodate speaker locality (9am-11pm CEST / 12am-2pm PDT). And it was free!

With all these positive attributes, it wasn’t a surprise that so many people attended. During Martin’s keynote that came in the middle of the event–afternoon for CEST, early morning for PDT–there were around 550 people watching the Twitch feed! Most talks had over 100 people, which is a lot compared to most in-person conferences!

Some of my favorite talks from Scala Love:

A Scala 3 Update, Martin Odersky
- Finally convinced me of the goodness of Scala 3. Also, he admitted before the talk he didn’t get to see the other talks because he was busy finishing his slides! He’s just like us!

somebody showed up for @scala_love! @odersky pic.twitter.com/BXxYH5GLow
— Adam Rosien (@arosien) April 18, 2020

Counts, Combinations, Dice, and D&D, Rúnar Bjarnason
- An irresistable subject to a kid who loved Dungeons and Dragons, but also included some algebraic structures related to multisets that were new to me.
Cats Effect 3: What, When, Why, Daniel Spiewak
- As a cats-effect user who is also creating a course for effects, I wanted to know more about the limitations of the current design, and where it is going. It was at the same time as Michael Pilquist’s Scodec for Scala 3. I wish I could have attended both!

As a Speaker

As a speaker it’s very difficult to gauge the audience’s reactions when you can’t see or hear them (laugh at your jokes). Speakers need lots of feedback to give engaging and meaningful talks, and most speakers didn’t check in with their audience very often, or at all. We need to explore how to get this signal back to the speakers: encourage more activity in chat, run periodic structured queries to the audience, mass video broadcasting so everyone can see everyone else, and so on.

At the same time, attendees at an in-person conference have no, or vastly reduced, distractions compared to an online conference. Most online attendees were at home or work, which means you don’t get their full attention as there is an expectation they will do parts of their usual work or home routine. To balance this I think it might be better for online conferences to run shorter days—say 3 hours instead of a whole day—as it is much easier to block out the time for a shorter period.

Both conferences had per-track moderators that helped speakers set up and get comfortable, and then gave introductions and helped moderate questions during and after the talk. As a speaker, these helpers felt more involved than in-person conferences, probably because they had so much more to deal with: screen-sharing, multiple chat systems, and so on. They did great.

As an Attendee

As an attendee, the first issue that came up for me after hearing a talk was, “how do I clap?”, to let them know I appreciated their talk. I think everyone immediately had similar thoughts. As an audience we didn’t have many options available, so we started putting clapping emoji (👏) into the chat rooms. I think it worked well, and it was exciting to see the chat start scrolling quickly with clapping everywhere:

Example chat with applause during NEScala. Image stolen from Ryan Williams's NEScala post-mortem.

Secondly, in a “normal” conference setting there is time, and most importantly, space, between talks for people to meet and talk. Conferences had breakout rooms, but I think we, as the attendees, didn’t know how to use them. Maybe we need more structure imposed on us, since we don’t have the physical cues available, with facilitators to keep the conversations flowing?

Last, a bit of a minor benefit of being online: I liked that the attendees could closely experience the pre-talk setup time between the organizers and speakers, instead of merely becoming introduced to the speaker when their talk began. It humanizes the difficult tasks of a conference, and helps the audience connect with the people making it happen.

Summary

Online-only conferences will be the new normal, and they can be as good, or even better in some regards, than the traditional in-person form. For example, in a world where speakers don’t have to travel, conferences have access to so many more wonderful and talented people. And conferences can be much larger for the same reason, no one has to travel in order to attend.

I didn’t mention it earlier, but the organizers, moderators and helpers for both NEScala and Scala Love were fantastic! Everyone was very responsive across all the various pieces of software we were using. After the conference, I was happy to see many thank-you’s to them on social media.

Let us know what you think about our new world!

Appendix: Conference Details to Compare and Contrast

NEScala:

CFP: community-curated (attendees voted on the submitted talks)
Duration: 3 days
Tracks: 1
Cost: $120
Video: Zoom
Chat: Slack, Zoom

Scala Love:

CFP: organizer-curated
Duration: 1 day (14 hours!)
Tracks: 2 + 1 (extra track managed by JetBrains)
Cost: $0
Video: Zoom (registered attendees), Twitch (public)
Chat: Slack, Zoom, Twitch

Functional Programming Demystification at Seattle's Scala Meetup

2020-05-20T00:00:00Z

Last night I was the speaker at Seattle’s Scala meetup, Scala at the Sea. The topic was “Functional Programming Demystification”:

Functional programming is full of Fancy Words™. Let's collect a list of them to demystify together. Adam will facilitate with live-coding, and will also try to make good jokes.

Here’s some terms to bootstrap us: effect, free monad, functor, property-based testing, refinement type, stream, etc.

We will have plenty of time for Q&A during this session.

I also shared our newly available public course, Essential Effects, with the group.

We didn’t get to all of the terms we collected, but we did cover functor, monad, and effects, with a side-topic about typeclasses, before we ran out of time.

I’ve posted my notes and code on Github.

We’ve moved online via Zoom for our monthly gatherings, and it was good to reconnect with everyone there. However, as a speaker it is really difficult to talk to an audience you can’t see, and having only Q&A and text-based chat to interact is very frustrating. I hope we as a community can find more interactive ways of gathering together. We need to at least see each other’s faces!

Addendum to Alex N's blog post on Scala warnings

2020-05-29T00:00:00Z

Alexandru Nedelcu recently wrote Fatal Warnings and Linting in Scala, where amongst other things, I learned about the new @nowarn annotation in Scala 2.13, which allows you to selectively disable compiler warnings.

Of course, you be shouldn’t be locally suppressing compiler warnings very often. Why might you do this?

In my case, I’m writing exercises for our upcoming “Essential Effects” course (sorry, I couldn’t resist the plug!). When writing exercises, you want to provide a good code skeleton, so the student can concentrate on the essential details of the problem. I usually mark the the sections the student needs to implement with the ??? method. For example:

import cats.effect._

object HelloWorld extends IOApp {
  def run(args: List[String]): IO[ExitCode] =
    helloWorld.as(ExitCode.Success)

  val helloWorld: IO[Unit] = ??? // TODO: print "Hello World" to the console
}

Our friend the compiler helpfully reminds us dead code following this construct regarding the line with the ???.

But I don’t want my students to have these warnings, because they become errors, because I’ve also enabled -Xfatal-warnings, which turns all compiler warnings into errors. Alex’s article goes into more detail about why you should also enable -Xfatal-warnings.

So it’s a bit of a conundrum: we don’t want warnings, because they are probably errors, but we now have errors–due to warnings–that we don’t want to bother the student with.

The @nowarn annotation let’s us locally suppress the warning:

import cats.effect._

object HelloWorld extends IOApp {
  def run(args: List[String]): IO[ExitCode] =
    helloWorld.as(ExitCode.Success)

  @annotation.nowarn
  val helloWorld: IO[Unit] = ??? // TODO: print "Hello World" to the console
}

But what if our diligent student completes the exercise? Now there aren’t actually any compiler warnings, but the code is marked with @nowarn. In my mind, the programmer should be notified of this, but unfortunately, there is no warning about this condition by default! We wouldn’t want any future revisions of this code, which might introduce warnings, to not have those warnings surfaced.

import cats.effect._

object HelloWorld extends IOApp {
  def run(args: List[String]): IO[ExitCode] =
    helloWorld.as(ExitCode.Success)

  @annotation.nowarn // There's no warning being suppressed!
  val helloWorld: IO[Unit] = IO(println("Hello World"))
}

To avoid this situation, you need to enable the -Wunused:nowarn compiler flag. Once added, if there exist any @nowarn annotations, but no warnings were actually suppressed, you’ll see this warning from the compiler: @nowarn annotation does not suppress any warnings. Now the programmer can remove the annotation. Huzzah!

In summary, if you’re on Scala 2.13 and are using @nowarn, please enable the -Wunused:nowarn compiler flag!

What Functional Programming Is, What it Isn't, and Why it Matters

2020-06-10T00:00:00Z

The programming world is moving towards functional programming (FP). More developers are using languages with an explicit bias towards FP, such as Scala and Haskell, while object-oriented (OO) languages and their communities adopt FP features and practices. (A striking example of the latter is the rise of Typescript and React in the Javascript community.) So what is FP and what does it mean to write code in a functional style? It’s common to view functional programming as a collection of language features, such as first class functions, or to define it as a programming style using immutable data and pure functions. (Pure functions always return the same output given the same input.) This was my view when I started down the FP route, but I now believe the true goals of FP are enabling local reasoning and composition. Language features and programming style are in service of these goals. In this post I attempt to explain the meaning and value of local reasoning and composition.

What Functional Programming Is

I believe that functional programming is a hypothesis about software quality: that software that can be understood before it is run and is built of small reusable components is easier to write and maintain. The first property is known as local reasoning, and the second as composition. Let’s address each in turn.

Local reasoning means we can understand pieces of code in isolation. When we see the expression 1 + 1 we know what it means regardless of the weather, the database, or the current status of our Kubernetes cluster. None of these external events can change it. This is a trivial and slightly silly example, but it illustrates a point. A goal of functional programming is to extend this ability across our code base.

It can help to understand local reasoning by looking at what it is not. Shared mutable state is out because relying on shared state means that other code can change what our code does without our knowledge. It means no global mutable configuration, as found in many web frameworks and graphics libraries for example, as any random code can change that configuration. Metaprogramming has to be carefully controlled. No monkey patching, for example, as again it allows other code to change our code in non-obvious ways. As we can see, adapting code to enable local reasoning can mean quite some sweeping changes. However if we work in a language that embraces functional programming this style of programming is the default.

Composition means building big things out of smaller things. Numbers are compositional. We can take any number and add one, giving us a new number. Lego is also compositional. We compose Lego by sticking it together. In the particular sense we’re using composition we also require the original elements we combine don’t change in any way when they are composed. When we create by 2 by adding 1 and 1 we get a new result but we don’t change what 1 means.

We can find compositional ways to model common programming tasks once we start looking for them. React components are one example familiar to many front-end developers: a component can consist of many components. HTTP routes can be modelled in a compositional way. A route is a function from an HTTP request to a handler function or a value indicating the route did not match. We can combine routes as a logical or: try this route or, if it doesn’t match, try this other route. Processing pipelines are another example that often use sequential composition: perform this pipeline stage and then this other pipeline stage.

Types

Types are not strictly part of functional programming but statically typed FP is the most popular form of FP and sufficiently important to warrant a mention. Types help compilers generate efficient code but types in FP are as much for the programmer as they are the compiler. Types express properties of programs, and the type checker automatically ensures that these properties hold. They can tell us, for example, what a function accepts and what it returns, or that a value is optional. We can also use types to express our beliefs about a program and the type checker will tell us if those beliefs are incorrect. For example, we can use types to tell the compiler we do not expect an error at a particular point in our code and the type checker will let us know if have made an incorrect assumption. In this way types are another tool for reasoning about code.

Type systems push programs towards particular designs, as to work effectively with the type checker requires designing code in a way the type checker can understand. As modern type systems come to other languages they naturally tend to shift programmers in those languages towards a FP style of coding.

What Functional Programming Isn’t

In my view functional programming is not about immutability, or keeping to “the substitution model of evaluation”, and so on. These are tools in service of the goals of enabling local reasoning and composition, but they are not the goals themselves. Code that is immutable always allows local reasoning, for example, but it is not necessary to avoid mutation to still have local reasoning. Here is an example of summing a collection of numbers. First we have the code in Typescript:

function sum(numbers: Array<number>): number {
    let total = 0.0;
    numbers.forEach(x => total = total + x);
    return total;
}

Here’s the same function in Scala:

def sum(numbers: List[Int]): Int = {
  var total = 0.0
  numbers.foreach(x => total = total + x)
  total
}

In both implementations we mutate total. This is ok though! We cannot tell from the outside that this is done, and therefore all users of sum can still use local reasoning. Inside sum we have to be careful when we reason about total but this block of code is small enough that it shouldn’t cause any problems.

In this case we can reason about our code despite the mutation, but neither the Typescript nor the Scala compiler can determine that this is ok. Both languages allow mutation but it’s up to us to use it appropriately. A more expressive type system, perhaps with features like Rust’s, would be able to tell that sum doesn’t allow mutation to be observed by other parts of the system^[1]. Another approach, which is the one taken by Haskell, is to disallow all mutation and thus guarantee it cannot cause problems.

Mutation also interferes with composition. For example, if a value relies on internal state then composing it may produce unexpected results. Consider generators in Javascript. They maintain internal state that is used to generate the next value. If we have two generators we might want to combine them into one generator that yields values from the two inputs. Here’s the code in Typescript:

type Gen<a> = Generator<a, void, never>

function* infinite(): Gen<number> {
    let index = 0;

    while (true) {
        yield index++;
    }
}

function zip<a, b>(left: Gen<a>, right: Gen<b>): Gen<[a, b]> {
    function* zipIt () {
        const l = left.next();
        const r = right.next();
        if (!l.done && !r.done) {
            const result: [a, b] = [l.value, r.value];
            yield result;
        }
    }

    return zipIt();
}

This works if we pass two distinct generators to zip.

zip(infinite(), infinite()).next().value; // [0, 0]

However if we pass the same generator twice we get a surprising result.

const inf = infinite();
zip(inf, inf).next().value; // [0, 1]

The usual functional programming solution is to avoid mutable state but we can envisage other possibilities. For example, an effect tracking system would allow us to avoid combining two generators that use the same memory region. These systems are still research projects, however.

So in my opinion immutability (and purity, referential transparency, and no doubt more fancy words that I have forgotten) have become associated with functional programming because they guarantee local reasoning and composition, and until recently we didn’t have the language tools to automatically distinguish safe uses of mutation from those that cause problems. Restricting ourselves to immutability is the easiest way to ensure the desirable properties of functional programming, but as languages evolve this might come to be regarded as a historical artifact.

Why It Matters

I have described local reasoning and composition but have not discussed their benefits. Why are they are desirable? The answer is that they make efficient use of knowledge. Let me expand on this.

We care about local reasoning because it allows our ability to understand code to scale with the size of the code base. We can understand module A and module B in isolation, and our understanding does not change when we bring them together in the same program. By definition if both A and B allow local reasoning there is no way that B (or any other code) can change our understanding of A, and vice versa. If we don’t have local reasoning every new line of code can force us to revisit the rest of the code base to understand what has changed. This means it becomes exponentially harder to understand code as it grows in size as the number of interactions (and hence possible behaviours) grows exponentially. We can say that local reasoning is compositional. Our understanding of module A calling module B is just our understanding of A, our understanding of B, and whatever calls A makes to B.

We introduced numbers and Lego as examples of composition. They have an interesting property in common: the operations that we can use to combine them (for example, addition, subtraction, and so on for numbers; for Lego the operation is “sticking bricks together”) give us back the same kind of thing. A number multiplied by a number is a number. Two bits of Lego stuck together is still Lego. This property is called closure: when you combine things you end up with the same kind of thing. Closure means you can apply the combining operations (sometimes called combinators) an arbitrary number of times. No matter how many times you add one to a number you still have a number and can still add or subtract or multiply or…you get the idea. If we understand module A, and the combinators that A provides are closed, we can build very complex structures using A without having to learn new concepts! This is also one reason functional programmers tend to like abstractions such a monads (beyond liking fancy words): they allow us to use one mental model in lots of different contexts.

In a sense local reasoning and composition are two sides of the same coin. Local reasoning is compositional; composition allows local reasoning. Both make code easier to understand.

The Evidence for Functional Programming

I’ve made arguments in favour of functional programming and I admit I am biased—I do believe it is a better way to develop code than imperative programming. However, is there any evidence to back up my claim? There has not been much research on the effectiveness of functional programming, but there has been a reasonable amount done on static typing. I feel static typing, particularly using modern type systems, serves as a good proxy for functional programming so let’s look at the evidence there.

In the corners of the Internet I frequent the common refrain is that static typing has neglible effect on productivity. I decided to look into this and was surprised that the majority of the results I found support the claim that static typing increases productivity. For example, the literature review in this dissertation (section 2.3, p16–19) shows a majority of results in favour of static typing, in particular the most recent studies. However the majority of these studies are very small and use relatively inexperienced developers—which is noted in the review by Dan Luu that I linked. My belief is that functional programming comes into its own on larger systems. Furthermore, programming languages, like all tools, require proficiency to use effectively. I’m not convinced very junior developers have sufficient skill to demonstrate a significant difference between languages.

To me the most useful evidence of the effectiveness of functional programming is that industry is adopting functional programming en masse. Consider, say, the widespread and growing adoption of Typescript and React. If we are to argue that FP as embodied by Typescript or React has no value we are also arguing that the thousands of Javascript developers who have switched to using them are deluded. At some point this argument becomes untenable.

This doesn’t mean we’ll all be using Haskell in five years. More likely we’ll see something like the shift to object-oriented programming of the nineties: Smalltalk was the paradigmatic example of OO, but it was more familiar languages like C++ and Java that brought OO to the mainstream. In the case of FP this probably means languages like Scala, Swift, Kotlin, or Rust, and mainstream languages like Javascript and Java continuing to adopt more FP features.

Final Words

I’ve given my opinion on functional programming—that the real goals are local reasoning and composition, and programming practices like immutability are in service of these. Other people may disagree with this definition, and that’s ok. Words are defined by the community that uses them, and meanings change over time.

Functional programming emphasises formal reasoning, and there are some implications that I want to briefly touch on. Later articles may expand on these points.

Firstly, I find that FP is most valuable in the large. For a small system it is possible to keep all the details in our head. It’s when a program becomes too large for anyone to understand all of it that local reasoning really shows its value. This is not to say that FP should not be used for small projects, but rather that if you are, say, switching from an imperative style of programming you shouldn’t expect to see the benefit when working on toy projects.

The formal models that underlie functional programming allow systematic construction of code. This is in some ways the reverse of reasoning: instead of taking code and deriving properties and start from some properties and derive code. This sounds very academic but is in fact very practical and how I, for example, develop most of my code.

Finally, reasoning is not the only way to understand code. It’s valuable to the limitations of reasoning, other methods for gaining understanding, and using a variety of strategies depending on the situation.

The example I gave is fairly simple. A compiler that used escape analysis could recognize that no reference to total is possible outside sum and hence sum is pure (or referentially transparent). Escape analysis is a well studied technique. In the general case the problem is a lot harder. We’d often like to know that a value is only referenced once at various points in our program, and hence we can mutate that value without changes being observable in other parts of the program. This might be used, for example, to pass an accumulator through various processing stages. To do this requires a programming language with what is called a substructural type system. Rust has such a system, with affine types. Linear types are in development for Haskell. ↩︎

Scoring Ten-pin Bowling with Algebraic Data and Finite State Machines

2020-06-18T00:00:00Z

I recently led a training session where we implemented the rules for scoring ten-pin bowling in Scala. It makes for a good case study. It’s small enough that you can pick up the rules in a few minutes, but the dependencies between frames makes calculating the score non-trivial. I decided to implement my own solution which turned into an interesting exercise in algebraic data and finite state machines. In this post I’ll describe my implementation and my process for developing it.

For my implementation I solely focused on scoring the game. I didn’t implement any parsing code, as that part of the problem didn’t interest me.

The Data

The core of my approach is getting the data structure right. Once they’re in place the rest of the code is relatively straightforward. This approach relies on some foundational features of functional programming, namely algebraic data types and structural recursion. Lets have a quick diversion into these topics.

Algebraic Data Types and Structural Recursion

“Algebraic data type” is a fancy phrase that functional programmers use to refer to data that is modelled in terms of logical ands and logical ors. Here are some examples:

a User is a name and an email address and a password;
a Result is a success or a failure;
a List of A is:
- the empty list (conventionally called nil) or
- a pair (conventionally called cons) containing a head of type A and a tail of type List of A.

If a language has support for algebraic data types, once we have a description of data such as the examples above we can directly translate it into code. Let’s use the example of the list as it is the most complex.

Here’s how we can define it in Scala.

sealed trait List[A]
final case class Nil[A]() extends List[A]
final case class Cons(head: A, tail: List[A]) extends List[A]

Here’s the same thing in Typescript.

type Nil<A> = { kind: "nil" }
type Cons<A> = { kind: "cons", head: A, tail: List<A> }
type List<A> = Nil<A> | Cons<A>

const Nil = <A>(): List<A> => 
  ({ kind: "nil" });
const Cons = <A>(head: A, tail: List<A>): List<A> => 
  ({ kind: "cons", head: head, tail: tail });

Here’s Rust.

enum List<A>{
    Nil,
    Cons(A, Box<List<A>>)
}

Each language requires some language specific knowledge in the implementation. For example:

in Scala we can choose between covariance and invariance;
in Typescript we need to define constructors seperately;
in Rust we must wrap recursion in a Box.

The general concept, however, applies to all these languages and we can transfer knowledge from one language to another. To avoid writing all the code three times for the rest of this post I’ll be sticking to Scala.

Given an algebraic data type we can implement any transformation on that type using structural recursion (also known as a fold or a catamorphism)^[1]. The rules, informally, for structural recursion are:

each case (logical or) in the data must have a case in the structural recursion; and
if the data we are processing is recursive the function we are defining must be recursive at the same place.

Structural recursion cannot solve everything for us—we must add problem-specific code to fill out the implementation—but it gives us a substantial help.

Here’s one way we could write the structural recursion skeleton for a list in Scala.

def transform[A](list: List[A]): SomeResultType =
  list match {
    case Nil() => 
      ???  // Problem specific
    case Cons(h, t) => 
      ??? // Problem specific but *must* include the recursion transform(t)
  }

If we want to calculate the length of a list we can start with the skeleton

def length[A](list: List[A]): Int =
  list match {
    case Nil() => 
      ???  // Problem specific
    case Cons(h, t) => 
      ??? // Problem specific but *must* include the recursion length(t)
  }

and fill out the problem specific parts

def length[A](list: List[A]): Int =
  list match {
    case Nil() => 
      0
    case Cons(h, t) => 
      1 + length(t)
  }

Any (yes, really, any) other method we can write that transforms a list to something else (or even another list) is going to have the same skeleton. So in summary, all we have to do is work out how to model our data using logical ands and ors and then we immediately get for free:

the representation of that data in code; and
a generic template for transforming that data into anything.

Diversion over! Let’s get back to bowling.

Bowling as an Algebraic Data Type

From reading the rules of bowling we can pull out a reasonably simple structure:

A game consists of 10 frames
Each frame can be a strike, a spare, or an open frame where
- an open frame is two rolls that sum to less than ten;
- a spare is one roll that is less than ten (the second rule is implied by the first roll); and
- a strike doesn’t need any additional information.

This is the model I started with but as I worked on it I realised the true model is more complicated because the final frame may have up to two bonus rolls. Hence I changed the model to

A game consists of 9 frames and 1 final frame
A frame can be a strike, a spare, or an open frame where
- an open frame is two rolls that sum to less than ten;
- a spare is one roll that is less than ten (the second roll is implied by the first roll); and
- a strike doesn’t need any additional information.
A final frame can be a strike, a spare, or an open frame which have the same definition as above and also
- a spare final frame has one bonus roll; and
- a strike final frame has two bonus rolls.

These definitions fit the criteria for an algebraic data type (they consist of logical ands and ors) and therefore translate to code in a straightforward way. Rather than paste a big lump of code I’ll just link to Frame, FinalFrame, and Game in the code repository. Note that not all the invariants can be expressed in the type system. For example, we cannot express the criteria that the rolls in an open frame must sum to less than 10. The problem specification says we only need to consider valid data, but I put some dynamic checks in the “smart constructors” on the companion objects. This turned out to be useful as it caught some errors in my tests (which I’ll talk about in a bit.)

Now that we have defined the data we just need to write a structural recursion over the Game type. Well, not quite. The scoring rules have dependencies between frames. For example, if a frame is a strike the next two rolls are added to the score for that frame. We need to keep around the information about pending frames—frames that have yet to be scored—while we process the data.

Reading through the rules we can extract the following.

The pending frames can be

a strike;
a spare; or
a strike and a strike .

This is another algebraic data type.

sealed trait Pending
case object Strike extends Pending
case object Spare extends Pending
case object StrikeAndStrike extends Pending

When we score a frame in a game we must calculate:

the score for this frame if it is not pending futures frames;
the score for any pending frames that are now complete; and
the pending frames after this frame.

In this way the scoring algorithm is a finite state machine (FSM). The pending frames are the current state of the FSM, the current frame is the output, and we output the next state (the updated pending frames) in addition to a score.

It’s useful to wrap the Pending information up with the score calculated so far, which gives all the information to calculate the total score so far. I called this State. Note that Pending is wrapped in an Option; there may be no frames for which the score is pending.

final case class State(
    score: Int,
    pending: Option[Pending]
) {
  def next(additionalScore: Int, newPending: Option[Pending]): State =
    this.copy(
      score = score + additionalScore,
      pending = newPending
    )
}

With this definition the scoring function has type (State, Frame) => State, which is exactly the type of the transition function of a FSM. We can calculate the score of a List[Frame] by passing this function as the second argument to foldLeft, with the initial state forming the first argument. In code this is

frames.foldLeft(initialState)(transitionFunction)

The transition function, the scoring algorithm, is a structural recursion over the Frame as well as the State. The code is lengthy, but it isn’t hard to write and a good deal of it is generated by the IDE (in my case, Metals with Doom Emacs.)

Testing

Testing was important. The scoring rules aren’t amenable to much support from the type system (though now I think about it I could have expressed the rules in a different way that would have given me more compiler support) which means testing is the next best way to ensure the code is correct. This is an excellent application for property-based testing, for which I used ScalaCheck.

I defined a few different generators for the various types of frames. For example here is how I generate open frames.

def genOpen: Gen[Frame] = {
  for {
    misses <- Gen.choose(1, 10)
    hits = 10 - misses
    roll1 <- Gen.choose(0, hits)
    roll2 = hits - roll1
  } yield Frame.open(roll1, roll2)
}

These generators enabled me to test both the examples given in the instructions and examples generated at random. I found quite a few errors with these tests, both in my scoring algorithm and in how I was generating data. Luckily they were all very easy to diagnose. As the scoring algorithm was very explicit it was easy to work out what I had done wrong (which was usually forgetting to include a roll somewhere).

Conclusions

I hope this article has given an insight in how I approached this case study. In summary there are three important components:

the core of my approach is to model the data correctly, as I know once I have the data model in place almost all of the rest of the code follows from it;
recognising the scoring algorithm was a finite state machine was another insight I needed to model it cleanly; and
using property-based testing allowed me to achieve a high degree of confidence in my implementation without a great deal of effort.

I have presented my process as if I moved straight from problem to implementation. This was not the case. It was a highly iterative process, and I changed the data model at least three times as I came to better understand the problem. I also interleaved developing the tests with the code under test.

Of course my approach is the only one. There is a write-up of a TDD approach in C# which may make an interesting contrast to mine.

Although this is well known in programming language theory I haven’t been able to find a reference that has a chance of being comprehensible to the average programmer. I think the first place to state this result is Data Structures and Program Transformation, but this uses the Bird-Meertens formalism which I find very hard to read. A tutorial on the universality and expressiveness of fold only considers folds on list, but uses Haskell and more standard mathematical notation. I imagine this is still quite obscure for most but it is an improvement! ↩︎

Techniques for Understanding Code

2020-07-07T00:00:00Z

Building an understanding of code is one of the main tasks in software development. Whenever we want to answer a question about code—what is this doing? why doesn’t it work? how can we make it faster?—this is what we’re doing. I have found it valuable to consciously surface the strategy I use to answer these questions, and have categorized my approaches into three groups:

reasoning about code;
inspecting running code; and
referring to an authoritative source.

In this post I will discuss these different ways of understanding code and their benefits and drawbacks.

Three Ways to Understand Code

Let’s start by describing the three methods for understanding code.

Reasoning

Reasoning means applying logic to some model of a programming language’s semantics. This sounds very formal, and that can be the case using say, an operational or denotational semantics. However most reasoning is informal. I’m sure the majority of programmers can reason about code (quick check: what does the program 1 + 1 evaluate to?) but would be hard pressed to specify the model and inference rules they use.

Reasoning takes place at many levels. For example, when I reason about code I might work at a low level that is easily reducible to a formal semantics. More often I work at a higher level, where I’m thinking about, say, transformations on algebraic data types instead of expressions and values.

Regardless of how it is done, reasoning requires a model and rules for inference.

Observation

Another way we can understand code is by observing its behavior as it runs. There are many ways to do this. Just running the program and looking at its output is probably most common, but other methods include using a debugger, inspecting logs, or runnning tests.

Appeal to Authority

A final way we can understand code is by turning to a trusted source. For most programmers this means the searching the Internet, perhaps using a site like Stack Overflow or a specialist forum or mailing list. It can also mean consulting a colleague or even, as a last resort, reading the fine manual.

The Advantages of Reasoning

Of the three methods my preference is to use reasoning. Reasoning can make statements that hold for all possible program runs. Let’s use the following code example to discuss this further. First the code is shown in Typescript.

function shout(phrase: string): string {
    return `${phrase.toUpperCase()}!`
}

Now here it is using Scala.

def shout(phrase: String): String =
  s"${phrase.toUpperCase}!"

Finally an example of using it.

shout("Hello, reader")
// Returns HELLO, READER!

Here are some of the properties of this code:

the string returned by shout will always end with an exclamation mark!
the code cannot fail unless passed null (or undefined in the case of Typescript.)
if the input is all in upper case the output will be one character longer.

There are other properties we could define but hopefully the above are sufficient to give you an idea of what I mean. We can tell these properties are true without running the code and they hold for all possible execution—an infinite number of cases.

Neither observation nor appealing to authority can prove statements about programs. Observation can only tell us about the properties of the program when run with the particular input it is given. If we see that the output of shout("Hello, reader") is "HELLO, READER!" then we might guess as to what shout is doing. More observations can increase our confidence. However we cannot ever be certain that we are correct by observation alone. Appealing to authority—perhaps by reading the documentation for the shout function—may describe what the function does but that description could be incorrect. The problem with trust is that it, well, relies on trust. Particularly when trusting randos on the Internet we must be cautious.

I find reasoning more efficient than other methods. If I have a good model of the domain I can reason my way out of most problems with just a little thinking. Observation requires I run a program, which usually takes more to setup, and consulting others requires I interrupt a colleague or trawl through hundreds of Internet search results.

Reasoning is also amenable to automation. The most accessible form of automated reasoning is probably type checking but linters and similar tools are other examples. Although there are systems that can construct tests they are not anywhere near as widely available as type systems. We might consider code reviews a kind of automated code review, but the feedback loop is much slower.

The Limit of Reasoning

There are theoretical and practical limits to the power of reasoning.

The halting problem demonstrates fundamental limits to the power of reasoning. There are some properties that we simply cannot prove for all programs. (The incompleteness theorems express the same idea from a mathematical perspective.) However this is not usually what causes problems in practice. In my (admittedly limited) experience, for the working programmer the limits more often come from the cost of reasoning, reasoning across system boundaries, and issues with assumptions built into models. Let’s address each of these in turn.

The first issue is perhaps the most important: reasoning can be just too expensive. The cost is usually that of learning. Most reasoning we do is informal, and the cost here is in acquiring a reliable mental model. All of us have limits on what we have time to learn and must choose to specialise to an extent. When reasoning formally we may already have a model but even then most of us do not have expertise to use a formal model efficiently. Some systems are too complex to reasonably build a model for. Attempting to build a cycle accurate CPU model, for example, is likely to be wasted effort. It’s much simpler to measure actual program performance.

System boundaries also limit our ability to reason. We can only formally reason up to the boundaries of our system; when we interact with the outside world all bets are off. I imagine many developers have had the experience of interacting with a web service that doesn’t adhere to its own specification. It doesn’t matter what the documentation says, and it doesn’t matter how we represent remote systems with types in our code; if the real world is different we must adapt. The only way we can reliably determine a remote system’s behavior is by interacting with it and seeing what happens.

Finally, all formal models are built on assumptions. For example, when we say that the program 1 + 1 always evaluates to 2 we are making assumptions such as: arithmetic won’t overflow, we aren’t going to run into CPU bugs, and we don’t have to worry about cosmic rays. Usually this is fine, but there are occasions where it is not. It is up to us to decide when our assumptions should be challenged.

Combining Reasoning, Observation, and Trust

I’ve presented reasoning, observation, and appeal to authority as alternatives but the truth is that they are complimentary. For example, we can take observations as a starting point for reasoning, and usually when debugging this is what we do. We can use reasoning to suggest optimizations that we then confirm with actual performance measurements. We implicitly rely on trust even in formal reasoning: trust that the model we work with is correct, the tools we are using are free from bugs, and those who taught us to reason did a good job. In my experience the skill is in realising which combination of techniques is appropriate in a given situation. Let me give two examples.

I don’t fully understand the Scala sbt build tool. When I do have to work with sbt I know I’m going to have to rely on reading documentation and trial and error—which is to say appeal to authority and observation. If my goal is to work with a plugin I’ll usually rely on that plugin’s documentation. If I’m working with something core to sbt I’ll go straight to the sbt documentation. I won’t usually search the web as a first choice because I don’t find it particularly reliable. One non-goal is developing a complete mental model of sbt. I don’t mind if this happens but I don’t have to modify my builds often enough that I think this worthwhile. Hence my reading is usually very task oriented—how do I do this?—versus understanding why things work the way they do.

In contrast I’ve recently been learning React and Typescript (hence the Typescript examples in recent posts.) Here my goal is to build a mental model. To this end I have read through most of the documentation with a focus on conceptual material. When I encounter a surprise when programming I actively try to inspect my mental model to see how it should be revised. This slows me down to start with but the time I spend learning is paid back every time I use the model I’ve learned.

Finally, I’ve noticed that some programmers have an over reliance on a particular technique for understanding, usually searching the web. I think it is important to build reliable mental models in our core skills, so if you are the type of person who jumps onto Google whenever you encounter a problem try instead to reason about it first, and then think how you need to adjust your mental model so you understand the cause of the error. I believe it will make you a better programmer in the long run.

What is an Effect?

2020-07-20T00:00:00Z

The following post is an excerpt of the first chapter of the companion book to our new course Essential Effects.

We often use the term effect when talking about the behavior of our code, like “What is the effect of that operation?” or, when debugging, “Doing that shouldn’t have an effect, what’s going on?”, where “what’s going on?” is most likely replaced with an expletive. But what is an effect? Can we talk about effects in precise ways, in order to write better programs that we can better understand?

To explore what effects are, and how we can leverage them, we’ll distinguish two aspects of code: computing values and interacting with the environment. At the same time, we’ll talk about how transparent, or not, our code can be in describing these aspects, and what we as programmers can do about it.

The Substitution Model of Evaluation

Let’s start with the first aspect, computing values. As a programmer, we write some code, say a method, and it computes a value that gets returned to the caller of that method:

def plusOne(i: Int): Int = // <1>
  i + 1

val x = plusOne(plusOne(12)) // <2>

Here are some of the things we can say about this code:

plusOne is a method that takes an Int argument and produces an Int value. We often talk about the type signature, or just signature, of a method. plusOne has the type signature Int => Int, pronounced "Int to Int" or "plusOne is a function from Int to Int".
x is a value. It is defined as the result of evaluating the expression plusOne(plusOne(12)).

Let’s use substitution to evaluate this code. We start with the expression plusOne(plusOne(12)) and substituting each (sub-)expression with its definition, recursively repeating until there are no more sub-expressions:

TIP: We’re displaying the substitution process as a “diff” you might see in a code review. The original expression is prefixed with -, and the result of substitution is prefixed with +.

Replace the inner plusOne(12) with its definition:

- val x = plusOne(plusOne(12))
+ val x = plusOne(12 + 1))

Replace 12 + 1 with 13:

- val x = plusOne(12 + 1))
+ val x = plusOne(13))

Replace plusOne(13) with its definition:
```
- val x = plusOne(13))
+ val x = 13 + 1
```
Replace 13 + 1 with 14:
```
- val x = 13 + 1
+ val x = 14
```

It is important to notice some particular properties of this example:

To understand what plusOne does, you don’t have to look anywhere except the (literal) definition of plusOne. There are no references to anything outside of it. This is sometimes referred to as local reasoning.
Under substitution, programs mean the same thing if they evaluate to the same value. 13 + 1 means exactly the same thing as 14. So does plusOne(12 + 1), or even (12 + 1) + 1.

To quote myself while teaching an introductory course on functional programming, “[substitution] is so stupid, even a computer can do it!”. It would be fantastic if all programs were as self-contained as plusOne, so we humans could use substitution, just like the machine, to evaluate code. But not all code is compatible with substitution.

When does substitution break down?

Take a minute to think of some examples of expressions where substitution doesn’t work. What about them breaks substitution?

Here are a few examples you might have thought of:

When printing to the console.

The println function prints a string to the console, and has the return type Unit. If we apply substitution,
```
- val x = println("Hello world!")
+ val x = ()
```
the meaning–the effect–of the first expression is very different from the second expression. Nothing is printed in the latter. Using substitution doesn’t do what we intend.
When reading values from the outside world.

If we apply substitution,
```
- val name = readLine
+ val name = <whatever you typed in the console>
```
name evaluates to whatever particular string was read from the console, but that particular string is not the same as the evaluation of the expression readLine. The expression readLine could evaluate to something else.
When expressions refer to mutable variables.

If we interact with mutable variables, the value of an expression depends any possible change to the variable. In the following example, if any code changes the value of i, then that would change the evaluation of x as well.
```
var i = 12

- val x = { i += 1; i }
+ val x = 13
```
(This example is very similar to the previous one.)

Dealing with Side-effects

The second aspect of effects, after computing values, is interacting with the environment. And as we’ve seen, this can break substitution. Environments can change, they are non-deterministic, so expressions involving them do not necessarily evaluate to the same value. If we use mutable state, if we perform hidden side-effects–if we break substitution–is all lost? Not at all.

One way we can maintain the ability to reason about code is to localize the “impure” code that breaks substitution. To the outside world, the code will look–and evaluate–as if substitution is taking place. But inside the boundary, there be dragons:

def sum(ints: List[Int]): Int = {
  var sum = 0 // <1>

  ints.foreach(i => sum += i)

  sum
}

sum(List(1, 2, 3)) // <2>

We’ve used a mutable variable. The horrors! But nothing outside of sum can ever affect it. Its existence is localized to a single invocation.
When we evaluate the expression that uses sum, we get a deterministic answer. Substitution works at this level.

We’ve optimized, in a debatable way, code to compute the sum of a list, so instead of using an immutable fold over the list we’re updating a local variable. From the caller’s point to view, substitution is maintained. Within the impure code, we can’t leverage the reasoning that substitution gives us, so to prove to ourselves the code behaved we’d have to use other techniques that are outside the scope of this book.

Localization is a nice trick, but won’t work for everything that breaks substitution. We need side-effects to actually do something in our programs, but side-effects are unsafe! What can we do?

The Effect Pattern

If we impose some conditions, we can tame the side-effects into something safer; we’ll call these effects. There are two parts:

The type of the program should tell us what kind of effects the program will perform, in addition to the type of the value it will produce.
One problem with impure code is we can’t see that it is impure! From the outside it looks like a method or block of code. By giving the effect a type we can distinguish it from other code. At the same time, we continue to track the type of the result of the computation.
If the behavior we want relies upon some externally-visible side-effect, we separate describing the effects we want to happen from actually making them happen. We can freely substitute the description of effects up until the point we run them.
This idea is exactly the same as the localization idea, except that instead of performing the side-effect at the innermost layer of code and hiding it from the outer layers, we delay the the side-effect so it executes outside of any evaluation, ensuring substitution still holds within.

We’ll call these conditions the Effect Pattern, and apply it to studying and describing the effects we use every day, and to new kinds of effects.

Example: Is `Option` an Effect?

The Option type represents the optionality of a value: we have some value, or we have none. In Scala it is encoded as an algebraic data type:

sealed trait Option[+A]

case class Some[A](value: A) extends Option[A]
case object None extends Option[Nothing]

Is Option[A] an effect? Let’s check the criteria:

Does Option[A] tell us what kind of effects the program will perform, in addition to the type of the value it will produce?
Yes: if we have a value of type Option[A], we know the effect is optionality from the name Option, and we know it may produce a value of type A from the type parameter A.
Are externally-visible side-effects required?
Not really. The Option algebraic data type is an interface representing optionality that maintains substitution. We can replace a method call with its implementation and the meaning of the program won’t change.

There is one exception–pun intended–where an externally-visible side-effect might occur:

def get(): A =
  this match {
    case Some(a) => a
    case None => throw new NoSuchElementException("None.get")
  }

Calling get on a None is a programmer error, and raises an exception which in turn may result in a stack trace being printed. However this side-effect is not core to the concept of exceptions, it is just the implementation of the default exception handler. The essence of exceptions is non-local control flow: a jump to an exception handler in the dynamic scope. This is not an externally-visible side effect.

With these two criteria satisfied, we can say yes, Option[A] is an effect!

It may seem strange to call Option an effect since it doesn’t perform any side-effects. The point of the first condition of the Effect Pattern is that the type should make the presence of an effect visible. A traditional alternative to Option would be to use a null value, but then how could you tell that a value of type A could be null or not? Some types which could have a null value are not intended to have the concept of a missing value. Option makes this distinction apparent.

Example: Is `Future` an Effect?

Future is known to have issues that aren’t easily seen. For example, look at this code, where we reference the same Future to run it twice:

val print = Future(println("Hello World!"))
val twice =
  print
    .flatMap(_ => print)

What output is produced?

Hello World!

It is only printed once! Why is that?

The reason is that the Future is scheduled to be run immediately upon construction. So the side-effect will happen (almost) immediately, even when other “descriptive” operations–the subsequent print in the flatMap—happen later. That is, we describe performing print twice, but the side-effect is only executed once!

Compare this to what happens when we substitute the definition of print into twice:

Replace the first reference to print with its definition:

  val print = Future(println("Hello World!"))
  val twice =
-   print
+   Future(println("Hello World!"))
      .flatMap(_ => print)

Replace the second reference to print with its definition, and remove the definition of print since it has been inlined.

- val print = Future(println("Hello World!"))
  val twice =
    Future(println("Hello World!"))
-     .flatMap(_ => print)
+     .flatMap(_ => Future(println("Hello World!")))

We now have:

val twice =
  Future(println("Hello World!"))
    .flatMap(_ => Future(println("Hello World!")))

Running it, we then see:

Hello World!
Hello World!

This is why we say Future is not an effect: when we do not separate effect description from execution, as per our Effect Pattern, substitution of expressions with their definitions doesn’t have the same meaning,

Capturing Arbitrary Side-Effects as an Effect

We’ve seen the Option effect type, which doesn’t involve side-effects, and we’ve examined why Future isn’t an effect. So what about an effect that does involve side-effects, but safely?

This is the purpose of the IO effect type in cats.effect. It is a data type that allows us to capture any side-effect, but in a safe way, following our Effect Pattern. We’ll first build our own version of IO to understand how it works.

A simple `MyIO` data type

case class MyIO[A](unsafeRun: () => A) { // <1>
  def map[B](f: A => B): MyIO[B] =
    MyIO(() => f(unsafeRun())) // <2>

  def flatMap[B](f: A => MyIO[B]): MyIO[B] =
    MyIO(() => f(unsafeRun()).unsafeRun()) // <2>
}

When we construct an MyIO value, we give it a function which computes the result and may perform side-effects, but don’t invoke it yet. When we want to execute the side-effect, we call unsafeRun.
We can compose our MyIO value to produce new MyIO values using map and flatMap. But notice we always create a new MyIO value, with its own delayed unsafeRun side-effect, to ensure no side-effects are executed until the outer unsafeRun is invoked.

For example, we might define printing to the console as an MyIO value:

def putStr(s: => String): MyIO[Unit] =
  MyIO(() => println(s))

val hello = putStr("hello!")
val world = putStr("world!")
val helloWorld =
  for {
    _ <- hello
    _ <- world
  } yield ()

helloWorld.unsafeRun()

which outputs

hello!
world!

`MyIO` as an Effect

Let’s check MyIO against our Effect Pattern:

Does the type of the program tell us…
a. What kind of effects the program will perform?
An MyIO represents a (possibly) side-effecting computation.
b. What type of value will it will produce?
A value of type A, if the computation is successful.
When externally-visible side-effects are required, is the effect description separate from the execution?
Externally-visible side-effects are required: the unsafeRun method of an MyIO can do anything, including side-effects.
We describe MyIO values by constructing them and by composing with methods like map and flatMap. The execution of the effect only happens when the unsafeRun method is called.

Therefore, MyIO is an effect!

By satisfying the Effect Pattern we know the MyIO effect type is safe to use, even when programming with side-effects. At any point before we invoke unsafeRun we can rely on substitution, and therefore we can replace any expression with its value–and vice-versa–to safely refactor our code.

The cats.effect.IO data type uses very similar techniques to isolate the captured side-effect from any methods used for composition.

Summary

The substitution model of evaluation gives us local reasoning and fearless refactoring.
Interacting with the environment can break substitution. We can localize these side-effects so they don’t affect evaluation.
The Effect Pattern is a set of conditions that makes the presence of effects more visible while ensuring substitution is maintained. An effect’s type tells us what kind of effects the program will perform, in addition to the type of the value it will produce. Effects separate describing what we want to happen from actually making them happen. We can freely substitute the description of effects up until the point we run them.
We created the MyIO[A] effect, which delayed the side-effect until the unsafeRun method is called. We produced new MyIO values with the map and flatMap combinators. cats-effect and other implementations of the IO monad allow us to safely program and refactor our programs, even in the presence of side-effects.

Context Bounds are Implicitly Passed, are Subtype Bounds?

2020-11-06T00:00:00Z

The question

What is it that makes Functor.widen safe? I think I remember someone explaining it at some point but I can’t remember. Something about “all functors are covariant” or something like that.

– @Billzabob in gitter.im/typelevel/cats

What does `Functor.widen` do?

Functor.widen lets you transform some container F[A] into F[B], if A is a subtype of B. For example, a list of cats can also be viewed as a list of animals:

import cats.implicits._

val cats: List[Cat] = ???
val animals: List[Animal] = cats.widen

(Naturally, Cat is a subtype of Animal in these examples.)

Now, using widen on a List is actually redundant, as List is marked as covariant: it is defined as List[+A]. The + before the type parameter A means covariant, and if something is covariant it means you can replace some F[A] with F[B], if A is a subtype of B. So we could have instead written:

val cats: List[Cat] = ???
val animals: List[Animal] = cats // no widen necessary, because List[+A]

We might actually use widen on a type that isn’t marked as covariant, such as cats.data.EitherT:

import cats._
import cats.data.EitherT
import cats.implicits._

val cat: EitherT[Id, Throwable, Cat] = ???
val animal: EitherT[Id, Throwable, Animal] = cat.widen

How is `Functor.widen` implemented?

Here’s the definition from Cats:

def widen[A, B >: A](fa: F[A]): F[B] = fa.asInstanceOf[F[B]]

We see the implementation is a type cast that is guarded by the subtype constraint B >: A: type B must be a supertype of type A. The compiler won’t allow the use of widen where the subtype relationship doesn’t hold.

Back to the Question

What is it that makes Functor.widen safe?

I replied–correctly–that widen is safe because:

the signature requires the super type witness: def widen[A, B >: A](fa: F[A]): F[B]

where I conflate the term “witness” (a value that “proves” some condition holds) with the presence of the subtype bound B >: A.

However, I then misspoke:

also remember that [B >: A] is actually passed as an implicit value ev: A <:< B, and <:<[A, B] extends Function1[A, B]

I thought that subtype bounds were syntactic sugar, just as context bounds are, but I was wrong! Recall that context bounds are a way to succinctly write typeclass instance constraints, so

def something[A : Monoid] // Monoid context bound

is desugared and equivalent to

def something[A](implicit m: Monoid[A]) // implicit Monoid typeclass instance

There is an analogous implicitly passed value for subtype bounds, but the subtype bound is not syntactic sugar for it. (I thought it was.) That is, the type signature

def widen[A, B >: A](fa: F[A]): F[B]

is equivalent to the type signature

def widen[A, B](fa: F[A])(implicit ev: A <:< B): F[B]

but the former is not converted to the latter by the compiler,
as is the case for context bounds. ("B is a supertype of A" is equivalent to "A is a subtype of B"; ev stands for “evidence”.)

What is this `<:<` type?

The higher-kinded type <:<[A, B] represents the subtype relationship between two types, where A is a subtype of B. Types with two parameters may be written infix, so the previous type is usually written as A <:< B. If you have a value of this type, then the subtype relationship holds.

As shown above, you can “summon” an implicit value (named ev above) of type A <:< B if type A is a subtype of B. The compiler will then supply the value if it exists.

What’s the point of having this alternate representation of the subtype relationship? If an A is a subtype of B, we can rely on the compiler to “automatically” cast an A into a B. Like a typeclass instance, you only need it if you’re going to use it, which begs the question, what can you do with a A <:< B?

Using a `<:<` value

It turns out that A <:< B is a subtype of the function type A => B:

trait <:<[A, B] extends Function1[A, B]

This makes sense: subtyping means we can transform a value of (sub-)type A into a value of (super-)type B. And the value ev: A <:< B is the function that can do that.

It’s not common to use this value explicitly, but the fact that it exists can help demystify covariance.

Covariance without subtypes

Covariance is usually explained in terms of containers and subtypes. That is, the covariant List[A] can be cast to a List[B] if A is a subtype of B. (Cue list of cats and animals example.)

What if we could “turn off” the covariant + annotation on List, but still perform the same conversion of the container? How might we implement that ourselves? Well, to convert one list into another, we can use map:

val cats: List[Cat] = ???
val animals: List[Animal] = cats.map(???)

We need to replace ??? with a function that converts a Cat into an Animal. That’s our implicit-subtype-evidence-function thing!

val cats: List[Cat] = ???
val ev: Cat <:< Animal = implicitly
val animals: List[Animal] = cats.map(ev)

Instead of viewing covariance as the ability to convert containers of subtypes into containers of supertypes, we can recast the former definition in terms of map with the “subtype evidence” function. Covariance is a more general phenomenon: the ability to map; that is, a (covariant) Functor.

Back to `Functor.widen`

We can rewrite Functor.widen to explicitly convert every element using the subtype evidence, rather than using the type casting machinery of the compiler:

def explicitWiden[A, B](fa: F[A])(implicit ev: A <:< B): F[B] =
  fa.map(ev)

(Remember, F is a Functor, so there is a map method available.)

The actual implementation of Functor.widen doesn’t use this definition, as it’s unnecessary to actually perform the sub- to supertype conversion given the semantics of Scala. So instead the implementation does a cast. But I find it very illuminating to know they are equivalent!

Summary

It is always possible to convert a value of a subtype to its supertype. This doesn’t require any extra code at runtime, only at compile-time.
You can get evidence of the subtype relation as an implicit parameter. This evidence has type <:<[A, B], which is most often written infix as A <:< B. The <:<[A, B] type extends Function1[A, B], because one can always tranform subtypes into supertypes.
Containers of a subtype can be transformed into containers of its supertype, if you can map over the container. The usual defintion of covariance emphasizes subtypes, but the ability to map is a more general, and useful, definition.

Concurrent state machines

2021-01-05T00:00:00Z

Noel recently tweeted about state machines,

Finite state machines are really a very useful abstraction. This is the kind of stuff that some dismiss as theoretical nonsense taught by time wasting CS departments, but from UIs to distributed systems life gets easier if you know and use FSMs.
— Noel Welsh (@noelwelsh) December 14, 2020

and that reminded me of concurrent state machines! Those must be even cooler!

The following is an excerpt from a chapter in my upcoming book, “Essential Effects”.

Concurrent state machines

Ref and Deferred are the building blocks of concurrency within Cats Effect. With Ref we can ensure atomic updates of shared state, and Deferred gives us the ability to serialize the execution of an effect with respect to some newly-produced state. Together we can build larger and more complex concurrent behaviors. One technique to do this is to create a concurrent state machine.^[1]

To build one we:

Define an interface whose methods return effects.
Implement the interface by building a state machine where:
1. state (with type S) is atomically managed via a Ref[IO, S] value;
2. each interface method is implemented by a state transition function affecting the Ref; and
3. any state-dependent blocking behavior is controlled via Deferred values.

As an example, we’ll follow this recipe to build a structure called a countdown latch.

Example: countdown latch

The behavior we’d like to model is to block subsequent effects until a certain number of (possibly concurrent) effects have occurred.

The metaphor of a latch is used because a latch is used to keep a door closed until the latch is opened. The term countdown refers to the algorithm for how the latch is opened: a counter is decremented, and when the counter reaches zero, the latch opens.

There are two logical roles that concurrently coordinate through the shared latch:

readers wait for the latch to open; and
writers decrement the latch counter.

The latch itself is responsible for “opening” when its counter reaches zero.

Let’s fulfill step one of our recipe (“define an interface whose methods return effects”) by encapsulating the actions of the two roles as methods on a shared CountdownLatch interface:

trait CountdownLatch {
  def await(): IO[Unit]     // <1>
  def decrement(): IO[Unit] // <2>
}

Readers will await the opening of the latch. The caller will be blocked and no value will be produced until the latch opens.
Writers will decrement the latch counter, which may open the latch.

A reader will be waiting for the latch to open, perhaps denoting a set of prerequite actions have occurred:

def actionWithPrerequisites(latch: CountdownLatch) =
  for {
    _ <- IO("waiting for prerequisites").debug
    _ <- latch.await // <1>
    result <- IO("action").debug // <2>
  } yield result

We block until the latch opens.
Once the latch opens, we can run the action.

(In these examples, debug is an custom extension method on an IO that is essentially defined as flatTap(a => IO(println(a))), printing the value produced to the console.)

At the same time, a writer is fulfilling one or more of those prerequisites:

def runPrerequisite(latch: CountdownLatch) =
  for {
    result <- IO("prerequisite").debug
    _ <- latch.decrement // <1>
  } yield result

Once the prerequisite action is completed, we decrement the latch.

Other code would run each of these roles concurrently:

val prepareAndRun =
  for {
    latch <- CountdownLatch(1)
    _ <- (actionWithPrerequisites(latch), runPrerequisite(latch)).parTupled
  } yield ()

It’s important to note that the two effects are only communicating through the shared CountdownLatch. They don’t directly know anything about each other.

When we run it we would see output like:

[ioapp-compute-1] waiting for prerequisites
[ioapp-compute-2] prerequisite
[ioapp-compute-1] action

Let’s implement it! A CountdownLatch will be in one of two states:

outstanding: we have n outstanding decrement() operations to expect; or
done: we have invoked decrement() n (or more) times.

We’ll encode the state–step 2.1 of our recipe–as an algebraic data type:

sealed trait State
case class Outstanding(n: Long, whenDone: Deferred[IO, Unit]) extends State
case class Done() extends State

For each method of the interface, the behavior of the latch will depend on its current state:

When a reader calls await():

If our state is Outstanding(n, whenDone), there are n outstanding decrement calls, so block the caller via whenDone.get.
If our state is Done(), do nothing.

When a writer calls decrement():

If our state is Outstanding(n, whenDone)
- If n is 1, this is the last decrement(). Transition to Done and unblock any blocked await() calls via whenDone.complete().
- Otherwise decrement n.
If our state is Done(), do nothing.

When we construct the CountdownLatch we’ll control concurrent access to the state with a Ref and create a Deferred to control our blocking behavior. We’ll then translate the state transitions into code almost exactly as previously described:

object CountdownLatch {
  def apply(n: Long)(implicit cs: ContextShift[IO]): IO[CountdownLatch] =
    for {
      whenDone <- Deferred[IO, Unit] // <1>
      state <- Ref[IO].of[State](Outstanding(n, whenDone)) // <2>
    } yield new CountdownLatch {
      def await(): IO[Unit] =
        state.get.flatMap { // <3>
          case Outstanding(_, whenDone) => whenDone.get // <4>
          case Done()                   => IO.unit
        }

      def decrement(): IO[Unit] =
        state.modify { // <5>
          case Outstanding(1, whenDone) => Done() -> whenDone.complete(()) // <6>
          case Outstanding(n, whenDone) =>
            Outstanding(n - 1, whenDone) -> IO.unit // <7>
          case Done() => Done() -> IO.unit
        }.flatten // <8>
    }
}

We create a Deferred[IO, Unit] that we’ll use to block and unblock await() callers.
We enforce atomic access to the current state with a Ref[IO, State] that we initialize to Outstanding with n expected decrements.
await() never changes the state, so we only act on the value from state.get.
If decrements are outstanding, we return a blocking effect that unblocks when the Deferred is completed.
decrement() always changes the state, so we use Ref.modify.
This is the last decrement, so we transition to Done and return an effect that completes the Deferred to unblock anyone who has invoked await().
We decrement the counter and return an effect which does nothing.
Our use of the state.modify method returns an IO[IO[Unit]], so we flatten it.

Voilà!

Summary

We built a countdown latch to model blocking subsequent effects until a certain number of (possibly concurrent) effects have occurred. We followed the concurrent state machine recipe:

1. Define an interface whose methods return effects.

We defined:

trait CountdownLatch {
	def await(): IO[Unit]
	def decrement(): IO[Unit]
}

2. Implement the interface by building a state machine where:

2.1. state (with type S) is atomically managed via a Ref[IO, S] value:

We initialize our state into a Ref

Ref[IO].of[State](Outstanding(n, whenDone))

where State is the algebraic data type

sealed trait State
case class Outstanding(n: Long, whenDone: Deferred[IO, Unit]) extends State
case class Done() extends State

2.2. each interface method is implemented by a state transition function affecting the Ref; and

We implement state-dependent behavior by pattern matching on the current state provided by the Ref.

Ref.modify lets us set the new state and return additional effects to be run.

2.3. any state-dependent blocking behavior is controlled via Deferred values.

We block when invoking await in the Outstanding state, and unblock any “await-ers” when invoking decrement if the counter reaches zero.

Blocking and unblocking are controlled by the get and complete methods of the whenDone: Deferred[IO, Unit] value.

By following this recipe, you too can build all sorts of control structures: mutexes, barriers, and more.

Fabio Labella introduced this technique and has popularized it through his talks and public commentary. You can watch his talks and learn more at https://systemfw.org. ↩︎

Recent and Upcoming Public Appearances

2021-02-11T00:00:00Z

We’ve had a few recent public appearances in the beginning of 2021, and more are upcoming:

Adam introduced the Cats Effect library and the release of his new book, Essential Effects, for the SF and Singapore Scala meetup groups. You can watch either version here or here. (Adam likes the second recording better because he had more practice.)
Adam was on The Scala Logs podcast talking about the release of Essential Effects and a bunch of other nerdy things. Take a listen!.
Noel will be presenting at the Scala Love in the City conference on Saturday, February 13, 2021. He’ll be presenting Finite State Machines for Functional Software Machinery, we hope you can attend!

Finite state machines (FSMs) are one of the simplest models of computation, but it’s this simplicity that makes them so useful. They are expressive enough to cover a wide range of practical problems while remaining easy to reason about. I believe they should be more widely used, and the only reason they aren’t is because many developers only know them in the context of a dusty theory of computation course. This talk sets out to change this!

I’ll first (re)introduce finite state machines as a model of computation. I’ll show that they are very simple, which makes them easy to understand and therefore create and debug. We’ll then see how finite state machines appear just about everywhere. We’ll see examples in the Scala standard library, and in application code from web services and user interfaces. We’ll finish by discussing implementation techniques and further applications.

Fire-and-Forget in Cats Effect

2021-03-09T00:00:00Z

I’ve noticed that often a lot of similar questions get asked within a few days of each other. Recently those questions have been about “fire-and-forget”, how it’s done in Cats Effect, and what issues one should be aware of. So I wrote up a little post with some background and techniques. Hope you enjoy it!

If you want to learn more about Cats Effect and concurrency, check out my book, Essential Effects!

What is “fire-and-forget”?

To understand fire-and-forget, let’s first distinguish it from a more typical method or function call whose purpose is to compute a value: a synchronous computation. We invoke the function, and can proceed once the value is produced.

def doSomething(i: Int): String = {
  println(s"[${Thread.currentThread.getName}] doSomething($i)")
  s"$i is a very nice number"
}

def doSomethingElse(): Int = {
  println(s"[${Thread.currentThread.getName}] doSomethingElse()")
  12
}

val doBoth = {
  val result = doSomething(12)
  println(s"[${Thread.currentThread.getName}] doSomething(12) produced: $result")
  doSomethingElse
}

Notice: all println outputs show the same thread.

Next let’s break down fire-and-forget. What’s fire?
It means to start a computation without waiting for its result, along with a way to access its eventual result: an asynchronous computation. (The term fire comes from the military, where a missile is launched. Eek!)

What would the type signature of such an asynchronous thing be? It requires the necessary inputs, but immediately returns to the caller. We’re not returning the “actual” result of the computation–we need to merely signal “ok, we’re starting, here is a value that lets you act on the eventual result”. We’ll model this as a trait with a fire method that returns an “eventual result” signal (as a function):

trait Asynchronous {
  type EventualResult[A] = () => A

  def fire[A](run: => A): EventualResult[A]
}

We can implement this interface using Scala’s Future type:

object Asynchronous {
  import scala.concurrent._
  import scala.concurrent.duration._

  val global = 
    new Asynchronous {
      implicit val ec = scala.concurrent.ExecutionContext.global

      def fire[A](run: => A): EventualResult[A] = {
        val res = Promise[A].completeWith(Future(run)) // start the computation
        () => Await.result(res.future, Duration.Inf)   // wait on demand
      }
    }
}

We then convert our synchronous code to use our Asynchronous interface:


val doBothAsync = {
  val await = Asynchronous.global.fire(doSomething(12))
  val result = await()
  println(s"[${Thread.currentThread.getName}] doSomething(12) produced: $result")
  doSomethingElse
}

Notice: The println for doSomething happens in a different thread than doSomethingElse.

Finally, we need to forget. That is, after we start the computation (fire), we don’t do anything with our handler to the eventual result. We “forget” it:

trait Asynchronous {
  type EventualResult[A] = () => A

  def fire[A](run: => A): EventualResult[A]
  
  def fireAndForget[A](run: => A): Unit =
    fire(run) // ignore the eventual result handler
}

object Asynchronous {
  import scala.concurrent._
  import scala.concurrent.duration._

  val global = 
    new Asynchronous {
      implicit val ec = scala.concurrent.ExecutionContext.global

      def fire[A](run: => A): EventualResult[A] = {
        val res = Promise[A]().completeWith(Future(run)) // start the computation
        () => Await.result(res.future, Duration.Inf) // wait on demand
      }
    }
}

The fireAndForget method invokes fire, which starts the asynchronous computation, but then ignores the returned EventualResult, meaning we won’t wait for any result at all.

Let’s update our example:

val doBothFireAndForget = {
  Asynchronous.global.fireAndForget(doSomething(12))
  doSomethingElse
}

Notice: we see the same asynchronous execution as the “fire”-only example, but don’t print out any intermediate results because we choose to not to wait for them.

Translating to Cats Effect

In Cats Effect, there are three parts to fire-and-forget:

Define the synchronous computation as an effect.
Fork the execution of the effect so it runs asynchronously (fire).
Ignore the return value of the fork (forget).

Let’s do it:

import cats.effect._
import cats.implicits._

class Something extends IOApp {

  def run(args: List[String]): IO[ExitCode] =
    doBoth.as(ExitCode.Success)

  def doSomething(i: Int): IO[String] = // <1>
    for {
      _ <- IO(println(s"[${Thread.currentThread.getName}] doSomething($i)"))
    } yield s"$i is a very nice number"

  def doSomethingElse(): IO[Int] =
    for {
      _ <- IO(println(s"[${Thread.currentThread.getName}] doSomethingElse()"))
    } yield 12

  val doBoth: IO[Int] =
    for {
      _ <- doSomething(12).start // <2> <3>
      i <- doSomethingElse
    } yield i
}

new Something().main(Array.empty)

We change the signature from returning String to returning IO[String], to signal the definition of a (synchronous) effect.
We start the IO effect value, forking its execution. It returns an IO[Fiber[IO, String]] (IO[FiberIO[String]] in Cats Effect 3) that lets you manage the asynchronous execution and eventual result.
We also ignore the Fiber produced by start by “anonymizing” its name as _.

Is it safe to “forget”?

When we fire-and-forget using Cats Effect, we’re deliberately not keeping track of the forked computation. Is there a cost to this–is it safe?

To answer, we need to recall what we can do with the fiber of the forked effect: we can wait for its completion (via join) or cancel it (via cancel). Since we really want asychronous execution, we will ignore join, leaving cancel: would it ever be necessary to cancel a computation that we fired and forgot?

It certainly could be important to do so! Consider a long-lived task, like an event-handling loop. We might think “oh, that effect runs forever, it doesn’t need to be canceled”, and therefore 🚀 + 🙈: fire-and-forget. But cancelation might be needed! That forked effect exists in some context; it might be important to ensure that it is cancelled if its “parent” context is cancelled:

val businessLogic =
  for {
    _ <- longLivedEffect.start
    _ <- doSomeOtherStuff
  } yield ()

In this example perhaps longLivedEffect should be cancelled when businessLogic completes, but fire-and-forget precludes that possibility. We could instead link the lifetime of that long-lived effect to the surrounding business logic. One way is to use guarantee:

val businessLogic =
  for {
    fiber <- longLivedEffect.start
    _ <- doSomeOtherStuff.guarantee(fiber.cancel) // <1>
  } yield ()

Cancel the fiber once the other logic completes successfully, with an error, or is cancelled.

But using guarantee doesn’t scale to multiple effects–for example, we want the fiber to be cancelled if any subsequent effect inside businessLogic is cancelled. We can instead model the lifecycle of an effect as a resource: a data structure that allows us to define a static region where state is used, along with effects for state acquisition and release:

val longLived: Resource[IO, IO[Unit]] =
  longLivedEffect.background // <1>

val businessLogic =
  longLived.use { join => // <2>
    doSomeOtherStuff
  }

Instead of calling start to fork the execution, background returns a Resource that manages the forked fiber for you. The managed state is itself an action–an IO[Unit] that lets you join the underlying fiber (if you want to).
Once we have a Resource, we use it to gain access to the managed state, where we can then perform our own effects. This defines a static region where the state is available, and outside this region we are guaranteed the state has been properly acquired and released. In the case of the resource returned by background, the state acquisition effect is “fork a fiber” and the release effect is “cancel the fiber”.

Summary

The pattern of fire-and-forget is really built out of three concepts:

defining synchronous effects;
forking an effect to run asynchronously; and
controlling the asynchronously executing effect, either waiting for its eventual result or canceling it.

If you have short-lived effects that you want to run asynchronously, by all means fire them off and forget about them! But also know that execution is always in some context, and you have techniques like background to make the asynchronous lifecycle more visible.

A Case Study in Incrementally Improving Code

2021-10-09T00:00:00Z

In this article I’m going to go through the process of improving some code. I’m mentoring a new developer who is applying for their first job. They were asked to complete some tasks on Codility as the first step of the interview process. To get used to the platform they did the first example task, and I advised them on some changes. I’m writing up here the progression from their code to (what I think is) better code. (Since this is the example task, not a task used to assess applicants, I think this is ok to publically post.)

The Problem

First, the Codility problem:

Write a function:
object Solution {
  def solution(a: Array[Int]): Int
}
that, given an array A of N integers, returns the smallest positive integer (greater than 0) that does not occur in A.

For example, given A = [1, 3, 6, 4, 1, 2], the function should return 5. Given A = [1, 2, 3], the function should return 4. Given A = [−1, −3], the function should return 1.

Write an efficient algorithm for the following assumptions:

N is an integer within the range [1…100,000];

each element of array A is an integer within the range [−1,000,000…1,000,000].

Setup

I created the interface below so that I could run all the variations through the same test harness. It’s not part of the specification from Codility or the student’s original code.

trait Solution {
  def solution(a: Array[Int]): Int
}

Initial Solution

Here’s the student’s initial solution:

object Solution1 extends Solution {

  def solution(a: Array[Int]): Int = {

    def tolis(b: List[Int]): Int = b match {
      case x :: Nil => x + 1
      case x :: hs => if ((hs.head - x) > 1) x + 1 else tolis(hs)

    }
    var b: List[Int] = a.toList.filter(_ > 0).sorted
    //b.sorted
    if (b.isEmpty) 1
    else if (b.head != 1) 1
    else tolis(b)


  }
}

Code Cleanup

There are several issues with the initial solution. Let’s start with the easiest ones:

confusing naming (what does tolis mean?)
var is not necessary (it could be a val)
messy formatting

These are fairly small points but they are easy for an interviewer to complain about. A lot of jobs, particularly entry level jobs, receive many applicants and interviewers are often looking for reasons to reject candidates. We don’t want to give them an easy reason to reject us!

Here’s the code after a quick clean up.

object Solution2 extends Solution {

  def solution(a: Array[Int]): Int = {
    def findLowest(numbers: List[Int]): Int = 
      numbers match {
        case x :: Nil => x + 1
        case x :: xs => if ((xs.head - x) > 1) x + 1 else findLowest(xs)
      }

    val clean: List[Int] = a.toList.filter(_ > 0).sorted

    if (clean.isEmpty) 1
    else if (clean.head != 1) 1
    else findLowest(clean)
  }
}

Testing the Solution

Before we move on to deeper issues, I want to create a test suite so we can be sure we don’t break anything during refactoring.
To test this function we could create a few hand-crafted cases, the programmer equivalent of banging together sticks to make fire, or we could generate test cases from a specification. A fairly simple way to generate test cases is:

create a many negative number as we like
create a sequence of positive numbers, and remove one of the numbers
join the two sets of numbers and shuffle

With this construction we know the result should be the number we removed.

Once we’ve setup the test suite we can proceed. I used MUnit and its ScalaCheck integration to do the above.

Partial and Total Functions

Let’s now move on to deeper issues. I don’t like the implementation of findLowest. There is some input for which it will crash—namely the empty list. In FP jargon we’d say it is a partial function, not a total function. The empty list case checked before it’s called, but it easy for future modifications to break this. We could use, say, Cats’ NonEmptyList type to express that this function only works with non-empty lists, but it’s not really appropriate to add a dependency in this context. We can, instead, rewrite findLowest to be a total function.

We can make findLowest a total function by adding an extra parameter, which is the current guess for the lowest number. With this we can write findLowest as a standard structural recursion and the compiler will stop complaining about our incomplete match. Here’s the code (written with Scala 3 syntax).

object Solution3 extends Solution {
  def solution(a: Array[Int]): Int = {
    def findLowest(result: Int, numbers: List[Int]): Int =
      numbers match {
        case Nil => result
        case x :: xs =>
          if result == x then findLowest(result + 1, xs) else result
      }

    val clean: List[Int] = a.toList.filter(_ > 0).sorted

    findLowest(1, clean)
  }
}

Performance

The requirements state they want an “efficient algorithm”. I don’t think they really mean that, but optimizing code can be fun and in this case there are some easy wins to be had. I’m going to look at two types of optimization:

data representation, where we change how we store data to be more efficient; and
algorithmic optimization, where we change the structure of the code to do less work.

The code mostly uses the List datatype, which is a singly linked list. This is a poor choice for performance as it involves a lot of pointer chasing and random memory access is slow on modern computers. List is appropriate when want to reason about shared data, and hence use immutable data, but in this code the data is never shared outside the method so that is not a concern.

From the algorithmic perspective we are doing a lot of work:

there is an O(n) traversal of the input to convert to a List;
the filtering operation is at least O(n) and may be more depending on how the filtered result is constructed;
sorting is O(n log n); and
the final traversal to find the lowest missing number is O(n).

My first change is mostly concerned with data representation. By working purely with arrays we use a more cache-friendly data structure, and we can also sort in-place which avoids some allocation. Here’s the code.

import java.util.Arrays

object Solution4 extends Solution {
  def solution(a: Array[Int]): Int = {
    def findLowest(result: Int, idx: Int, numbers: Array[Int]): Int = {
      if idx == numbers.length then result
      else if result == numbers(idx) then
        findLowest(result + 1, idx + 1, numbers)
      else result
    }

    val clean: Array[Int] = a.filter(_ > 0)

    Arrays.sort(clean)
    findLowest(1, 0, clean)
  }
}

The next step is mostly algorithmic optimization. We don’t need to sort the array, or even filter it. All we need to do is construct a data structure that tells us what numbers are present. This requires just one O(n) traversal through the input. We only need a single bit to represent presence or absence for each positive integer. The specification tells us the input will not be higher than 1,000,000. Hence we can use a bit-set consuming no more than about 125kB, which should easily fit into the L2 cache and might even squeeze into L1 cache. Once we have constructed the bit set we need a single O(n) traversal to find the lowest missing number. Here’s the code. Note I used java.util.BitSet instead of scala.collection.mutable.BitSet because it was a bit clearer on a quick glance which were the methods I wanted.

import java.util.Arrays
import java.util.BitSet

object Solution5 extends Solution {
  def solution(a: Array[Int]): Int = {
    def populateBitSet(
        bitSet: BitSet,
        idx: Int,
        numbers: Array[Int]
    ): BitSet = {
      if idx == numbers.length then bitSet
      else {
        val elt = numbers(idx)
        if elt < 1 then populateBitSet(bitSet, idx + 1, numbers)
        else {
          bitSet.set(elt)
          populateBitSet(bitSet, idx + 1, numbers)
        }
      }
    }

    val bitSet = populateBitSet(BitSet(1000000), 0, a)
    val result = bitSet.nextClearBit(1)
    result
  }
}

I setup a quick JMH benchmark to compare implementations. I was only looking for big improvements, so I’m only reporting results below for the first solution, and Solution4 and Solution5 above. As you can see the combination of data representation and algorithmic improvements yield a speed up a bit over ten times compared to the original. That’s pretty good for some fairly simple changes!

[info] CodilityBenchmark.benchSolution1 thrpt 3 741.060 ± 32.291 ops/s
[info] CodilityBenchmark.benchSolution4 thrpt 3 1956.945 ± 62.053 ops/s
[info] CodilityBenchmark.benchSolution5 thrpt 3 8406.225 ± 751.966 ops/s

Conclusions

The process of improving the code was reasonably straight forward. The most important improvements, in my opinion, are the ones that were done first. As an interviewer I want to see code that pays attention to clarity, as I think that’s one of the most important factors in successfully growing a large code base. The optimizations I performed require some level of knowledge of data structures, computer architecture, and algorithmic complexity. All these things should be covered in a computer science course but those who haven’t studied CS can find equivalents online. My optimizations don’t require a deep level of knowledge of, for example x86-64 architecture. All these optimizations can be reasoned about with a fairly coarse machine model.

All the code is on Github if you want go further, or just see how I setup the tests and benchmarks. I hope it is useful!

Functional Programming is Based

2023-03-13T00:00:00Z

Function programming is based^[1]; that is, based on principles that allow a systematic and repeatable process for creating software. In this post I’m going illustrate this process with an example of summing the elements of a list, inspired by this conversation. We’ll mostly be looking at algebraic data types and structural recursion (which often uses pattern matching, but is not synonymous with it).

For me, a working functional programmer, this process is one of the main advantages of FP. It means I can spend my mental cycles on understanding the problem, knowing that once I have done so the implementation follows in a straightforward way. The inverse also holds: if someone uses these principles to write code I can easily work out what problem it solves.

Overview

The main concepts we’ll discuss are:

algebraic data types, which builds up data; and
structural recursion, which tears down data.

As the description suggests, they go together. If we use an algebraic data type to define data, we can then use structural recursion to manipulate that data.

We’ll also see two reasoning principles for structural recursion, and we’ll take a quick look at the process for converting a function into a tail recursive form.

Functional programming has many of these concepts, which form the functional programming equivalent of design patterns in the object-oriented world. Like OO design patterns, they exist above the code and the representation in code often uses several language features. Unlike OO patterns they usually have a formal definition. Formality adds precision, but formal definitions are not very approachable. In my presentation below I’ll be quite informal.

Algebraic Data Types

Algebraic data types are data where individual elements are combined using logical ands and logical ors. For example, we could say a User data type consists of a name and an email address and a status. We might say a UserStatus is active or banned or suspended. All languages I know of that have some way of declaring data using logical ands, but most lack logical ors^[2].

A (singly linked) list is one of the simplest examples of an interesting algebraic data type. A List with elements of type A is either:

the empty List, or
a Pair with a head of type A and a tail of type List of A.

Notice in this example we have both an and and an or, and that the definition of list is recursive: a list contains a list in the tail of the Pair case.

There is a direct translation of this structure into code. In Scala 3 we have the following patterns:

If A is a B or C we write

enum A {
  case B
  case C
}

If A is a B and C we write^[3]

case A(b: B, c: C)

Taken together, and adding the syntax for generic types, we can write the definition of List:

enum List[+A] {
  case Empty
  case Pair(head: A, tail: List[A])
}

The point to note is that this Scala definition follows directly from the abstract definition of List and the patterns for algebraic data types in Scala. We could write a program to do the translation, if we so wanted.

Other languages with algebraic data types follow the same principles, with their own language specific quirks. For example,
in O’Caml we write type declarations backwards, with the generic type variable before the concrete type it applies to.

type 'a list =
  | Empty 
  | Pair of 'a * 'a list

In Rust we must add indirection for the recursion in the form of a Box, and worse, indent by 4 spaces instead of 2.

enum List<A> {
    Empty,
    Pair(A, Box<List<A>>)
}

We can also express algebraic data types in languages that don’t directly support them. In this case we have to rely on conventions instead of language support.

Structural Recursion

Structural recursion is the complement to algebraic data types. Algebraic data types tell us how to construct data. Structural recursion tells us how to transform that data into something else. In other words, how to deconstruct data. Any time we are working with an algebraic data type we can use structural recursion.

Structural recursion is often implemented using pattern matching, but pattern matching is not synonymous with structural recursion. We can implement structural recursion in other ways, and implement things that are not structural recursion using pattern matching. I’m going to use pattern matching in the example here, but keep this point in mind.

Given we have two patterns for structural recursion, ands and ors, we need two patterns for structural recursion. Once again, I’m using Scala 3 here.

If A is a B or C we write

anA match {
  case B => ???
  case C => ???
}

If A is a B and C we write
```
anA match {
  case A(b, c) => ???
}
```

The right-hand side of the match expressions, which I’ve filled in with ???, is where we implement our problem specific functionality.

There is one very important additional rule: when the data is recursive, the method we’re implementing is recursive in the same place.

An Example

Let’s see how structural recursion applies to implementing a method to sum the element in a list of integers. We start by defining the method header.

def sum(list: List[Int]): Int =
  ???

The first step is to recognize that list is an algebraic data type, and therefore we can use structural recursion to convert this list into the Int output we’re after. We start by filling out the structural recursion skeleton.

def sum(list: List[Int]): Int =
  list match {
    case Empty => ???
    case Pair(head, tail) => ???
  }

This is a direct application of the two structural recursion patterns to the List algebraic data type. However, I’ve forgotten one thing, the recursion rule! List is recursive in the tail of Pair, so sum should be recursive there. Let’s add that, giving us

def sum(list: List[Int]): Int =
  list match {
    case Empty => ???
    case Pair(head, tail) => ??? sum(tail)
  }

I’ve kept the ??? in place, indicating that we haven’t quite finished yet. This is as far as structural recursion on its own will take us, but we can finish the implementation with two reasoning principles.

Reasoning about Structural Recursion

To finish the implementation we can use two principles for reasoning about structural recursion:

we can consider each case independently; and
we can assume any recursive calls will return the correct value.

Starting with the code

def sum(list: List[Int]): Int =
  list match {
    case Empty => ???
    case Pair(head, tail) => ??? sum(tail)
  }

we’ll first look at the case for Empty. Remember we can consider it independently of the Pair case. So we simply need to ask ourselves “what is the sum of the empty list?” Zero is the only sensible answer here.

def sum(list: List[Int]): Int =
  list match {
    case Empty => 0
    case Pair(head, tail) => ??? sum(tail)
  }

Now we move on to the Pair case, where we can use the reasoning principle for recursion: assume it returns the value it should, which is the sum of the tail of the list. We can do this because the recursion comes from the recursion rule for structural recursion. So long as we take care of the non-recursive parts, the recursion is guaranteed to be correct.

Given this, we ask ourselves “if we have the sum of the tail of the list, what should sum of the tail and the head be?” The answer is to add the head to the sum of the tail.

def sum(list: List[Int]): Int =
  list match {
    case Empty => 0
    case Pair(head, tail) => head + sum(tail)
  }

With that we are done!

Notice that every step of the development of this method is justified by a general principle. This is what I mean by functional programming providing a systematic and repeatable process. Systematic because the process guides us along every step, and repeatable because we can apply the same process in many situations.

Tail Recursion

The sum method is not tail recursive, but once again there is a process to transform it into a tail recursive version. The steps of the transform^[4] are:

Identify what will summarize the data we’ve already seen at any point in the process. Here that is the partial sum of the list elements we’ve seen so far.

Add an additional method parameter to hold this value, usually called an accumulator.

def sum(list: List[Int], accum: Int): Int =
  list match {
    case Empty => 0
    case Pair(head, tail) => head + sum(tail)
  }

Change any base cases to return the accumulator.

def sum(list: List[Int], accum: Int): Int =
  list match {
    case Empty => accum
    case Pair(head, tail) => head + sum(tail)
  }

Change any recursive cases to update the accumulator and perform the recursion in tail position.

def sum(list: List[Int], accum: Int): Int =
  list match {
    case Empty => accum
    case Pair(head, tail) => sum(tail, head + accum)
  }

This explanation could do with more detail. I’ve skipped over the definition of tail position, for example. My goal here is to illustrate the process to someone who has already used it but is perhaps cannot articulate the underlying steps, rather than teach the process to someone who has no prior knowledge.

Conclusions

We’ve seen the following:

algebraic data types for modelling data expressed in terms or logical ands and ors;
structural recursion for transforming algebraic data types;
reasoning principles for completing structural recursions; and
conversion to tail recursive form.

There is a lot in this simple example. The most important point is that there is a process that explains every step of creating the method we’re after. This same process scales up to complex problems like compilers and graphics. This is a contrast to how I was taught imperative programming, and I think most programmers think about code, which is as a random collection of language features that combine in some ineffable way to produce working programs. In the context of the conversation that motivated this post, there is no need to even think about things like early returns. They simply aren’t a concept that is needed when you can produce working code using the patterns I’ve described.

The second point is applicable to languages that are adding “functional programming” features. For example, Python has recently added pattern matching. The real benefit of pattern matching, in my opinion, is not as a language feature on its own but as a tool for implementing structural recursion. This usually comes with compiler support for checking that all cases have patterns, known as exhaustivity checking. It is a mistake to think of functional programming as a collection of language features. The language features are in service to deeper ideas.

The third point is that functional programming is full of great stuff like this. The academic community has mostly done a terrible job communicating it to industry. For example, I believe algebraic data types and structural recursion were first explored in the antecedents of Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire. This paper has some of the most opaque notation I’ve ever read, and does a incredibly poor job of conveying incredibly interesting ideas. A notable exception is How to Design Programs, which presents algebraic data types and structural recursion in a way that completely new programmers can understand. I believe that making these patterns more accessible is the next step in the growth of functional programming.

“Based” is a term for something that is good or true, according to my children. ↩︎
Go is a great example of the problems caused by the absence of logical ors. Go functions return a success and an error value. The logical design would be to have function returning success or error values. Go’s design forces it to include a null value, the billion dollar mistake, because there needs to be some value to return for the success case when an error means there is no sensible value to return. Algebraic data types were fully formed by 1983 when Standard ML was created, while development on Go started 24 years later in 2007. One of the “primary considerations” for Go is “it must be modern”. ↩︎
There is an annoying irregularity in Scala 3’s syntax. For a case inside an enum we write what is given, but outside an enum we use a final case class instead. ↩︎
The full transform is known as continuation passing style and is a bit more complex than what I present here. ↩︎

Understanding Virtual Machine Dispatch through Duality

2023-12-19T00:00:00Z

For the next edition of Scala with Cats I’m writing a section on implementing interpreters. In my research I ended up going fairly deep down the rabbit hole of optimizations, in which virtual machine dispatch is a major area. There are many different approaches to dispatch, and I struggled to relate them until I realized they were all variations on a basic structure that resulted from applying the principle of duality. Duality is one of the major themes of the book, so I was happy to make this discovery. However I think going deep into optimization is not appropriate for the book so I’m writing this up here instead.

I’m going to first describe duality, then give context on interpreters and virtual machines, before moving on to the application of duality in virtual machine dispatch.

Duality

Duality, in mathematics, means making a direct correspondence between one structure and another structure. This in turn allows us to apply what we know from one structure to the other. There are many dualities in programming, which allows us to see different code structures as alternative implementations of some underlying concept. For example, function calls are dual to function returns. If we have a function that returns a value, like f in

val f: Int => Int = x => x + 40

val a = f(2)
val b = a * 2

we can, instead of returning that value, pass it to another function that does what we wanted to do with the value that was returned.

val f: (Int, Int => Int) => Int =
  (x, k) => k(x + 40)
  

val b = f(2, a => a * 2)

Asynchronous code using callbacks looks like this second style, and if you’re a programming language theory person you will recognize it as continuation passing style.

Duality doesn’t mean the two things are identical. Although the two examples above compute the same result they differ in other ways. The obvious difference is that in the second example the function f has two parameters. There is another difference. Function calls consume a stack frame, which a subsequent return frees. If we replace returns with calls we’ll never free any stack frames and so overflow the stack. Solving this leads us to tail calls.

A tail call is a function call that doesn’t consume a stack frame. A tail call can only replace a normal function call if the call is in tail position. A function call is in tail position if the result of the call is immediately returned. So the call to f below is in tail position.

def f(x: Int): Int = x * 2

def g(x: Int): Int = f(x + 42)

However the call to h below is not, because the result is used in the subsequent addition.

def h(x: Int): Int = x / 2

def g(x: Int): Int = h(x) + 4

Tail calls will be important is what comes later. To make them explicit I’ll going to invent a tailcall keyword to explicitly indicate them. So I’ll write

def g(x: Int): Int = tailcall f(x + 42)

to explicitly indicate that f is being called using a tail call.

There is another duality that we’ll need: that between data and functions. Wherever we have data, we can replace it with a function that does whatever it is we want to do with that data. For example, imagine choosing a contact to message from a list of contacts on your mobile phone. Instead of representing each contact as data containing a name, phone number, and so on, we can represent them as the action that initiates a message with them. We can extend this further to say the duality is between describing something in terms of what it is and in terms of what we can do with it. Describing what something is gives us data, while describing what we can do with it gives us functions (or objects, or codata depending on the terminology you want to use.) Again, this doesn’t mean that the two approaches are identical. They can achieve the same goal, but do it in different ways and have different properties.

Bytecode Interpreters and Virtual Machines

There are two common ways to implement an interpreter: by directly interpreting an abstract syntax tree, known as a tree-walking interpreter, or by compiling the abstract syntax tree to a linear sequence of instructions and then interpreting these instructions. This later case is known as a bytecode interpreter, as the instruction often, but not always, take up a single byte.

The instructions for a bytecode interpreter describe actions of some virtual machine. There are two common types of virtual machine: register machines and stack machines, of which stack machines are the most common. If we consider the code that implements each instruction as a function, in a stack machine these functions receive parameters from and return results to a stack. An instruction to add two integers would therefore pop two values from the stack, add them, and push the result back. Stack machines are simple to implement, but as this short example illustrates there can be considerable inefficiencies in moving values to and from the stack.

Imagine we’re implementing an interpreter for simple arithmetic. Our language consists of literals, addition, subtraction, multiplication, and division. In Scala we might define stack machine bytecode as

enum ByteCode {
  case Lit(value: Double)
  case Add
  case Sub
  case Mul
  case Div
}

Notice that the majority of operations have no parameters: these values come from the stack. In a register machine, the operations would have to specify registers where they find their parameters and the register where they store results.

Interpreter Dispatch

The core of a bytecode interpreter is instruction dispatch: choosing an instruction and then choosing the action to take given the instruction. Instruction dispatch has three components:

instruction fetch, which chooses the instruction to execute;
the actual dispatch, the chooses the action to take given the instruction that has been fetched; and
some kind of loop to continue the above two processes until the end of the program, if any, is reached.

Switch dispatch is the most common form of dispatch. This is named after the C language switch statement used to implement the dispatch component. Instruction fetch is often just an array reference, and the loop is usually an infinite while or for loop. In a functional language the loop would usually be a tail recursive function and the switch would usually be implemented by a pattern match over the instructions. More abstractly, instructions are an algebraic data type and switch dispatch is a structurally recursive loop.

Here’s a complete interpreter in Scala illustrating switch dispatch.

// The stack
val stack: Array[Double] = ???

// The program, a sequence of instructions
val instructions: Array[ByteCode] = ???

// sp is the *stack pointer*
// Its value is the index of the first free location in the stack
//
// ip is the *instruction pointer*
// Its value is the index of the current instruction in instructions
def dispatch(sp: Int, ip: Int): Unit = {
  // This simple language has no control flow, so we stop when
  // we reach the end of the instructions
  if ip == instructions.size then stack(sp - 1)
  else 
    // Fetch instruction
    val ins = instructions(ip)
    // Dispatch
    ins match {
      case Op.Lit(value) =>
        stack(sp) = value
        loop(sp + 1, ip + 1)
      case Op.Add =>
        val a = stack(sp - 1)
        val b = stack(sp - 2)
        stack(sp - 2) = (a + b)
        loop(sp - 1, ip + 1)
      case Op.Sub =>
        val a = stack(sp - 1)
        val b = stack(sp - 2)
        stack(sp - 2) = (a - b)
        loop(sp - 1, ip + 1)
      case Op.Mul =>
        val a = stack(sp - 1)
        val b = stack(sp - 2)
        stack(sp - 2) = (a * b)
        loop(sp - 1, ip + 1)
      case Op.Div =>
        val a = stack(sp - 1)
        val b = stack(sp - 2)
        stack(sp - 2) = (a / b)
        loop(sp - 1, ip + 1)
    }
}

Dispatch Through the Lens of Duality

The usual presentation of alternatives to switch dispatch (direct threading, indirect threading, and so on; we’ll see them in a moment) in my opinion confuses the code level realization and the conceptual level. For example, discussion of direct threading often talks about labels-as-values, a GCC extension. The differences between dispatch methods only became clear to me when I saw them as different realizations of the three components making up dispatch that utilized the dualities I’ve described earlier.

Starting with switch dispatch described above, let’s replace the bytecode instructions with functions that carry out the instructions, using the duality between data and functions. This gives us code like the following (where I’m leaving out bits that are unchanged from the previous code.)

val instructions: Array[Op] = ???

var sp: Int = 0

// An operation is a function () => Unit
sealed abstract class Op extends Function0[Unit]
final case class Lit(value: Double) extends Op {
  def apply(): Int = {
    stack(sp) = value
    sp = sp + 1
  }
}
case object Add extends Op {
  def apply(): Int = {
    val a = stack(sp - 1)
    val b = stack(sp - 2)
    stack(sp - 2) = (a + b)
    sp = sp - 1
  }
}
case object Sub extends Op {
  def apply(): Int = {
    val a = stack(sp - 1)
    val b = stack(sp - 2)
    stack(sp - 2) = (a - b)
    sp = sp - 1
  }

}
case object Mul extends Op {
  def apply(): Int = {
    val a = stack(sp - 1)
    val b = stack(sp - 2)
    stack(sp - 2) = (a * b)
    sp = sp - 1
  }
}
case object Div extends Op {
  def apply(): Int = {
    val a = stack(sp - 1)
    val b = stack(sp - 2)
    stack(sp - 2) = (a / b)
    sp = sp - 1
  }
}

def dispatch(ip: Int): Unit = {
  if ip == instructions.size then stack(sp - 1)
  else 
    // Fetch instruction
    val ins = instructions(ip)
    // Dispatch
    ins()
    // Loop
    loop(ip + 1)
}

This is known as subroutine threading in the literature. Notice that instructions can have parameters, like the Lit instruction above, and access the sp variable in their lexical environment. This means we need closures, or some equivalent representation. The literature often talks about how instruction parameters can be stored on the instruction stack alongside the instructions, but this detail, while important for performance, is not important to understanding the core of the concept.

Now we will utilize the duality between calls and returns to replace the returns in the instruction functions with (tail) calls to the next instruction. This moves the instruction fetch and dispatch into the instructions, giving us what is known as direct threading. Now the loop is implicit, spread throughout the instruction as a sequence of tail calls. The follow code illustrates direct threaded dispatch (where I’m again just showing the important bits.)

val instructions: Array[Op] = ???

var sp: Int = 0
var ip: Int = 0

// An operation is a function () => Unit
sealed abstract class Op extends Function0[Unit]
final case class Lit(value: Double) extends Op {
  def apply(): Int = {
    stack(sp) = value
    sp = sp + 1
    ip = ip + 1
    if ip == instructions.size then stack(sp - 1)
    else tailcall instructions(ip)()
  }
}
case object Add extends Op {
  def apply(): Int = {
    val a = stack(sp - 1)
    val b = stack(sp - 2)
    stack(sp - 2) = (a + b)
    sp = sp - 1
    ip = ip + 1
    if ip == instructions.size then stack(sp - 1)
    else tailcall instructions(ip)()
  }
}
case object Sub extends Op {
  def apply(): Int = {
    val a = stack(sp - 1)
    val b = stack(sp - 2)
    stack(sp - 2) = (a - b)
    sp = sp - 1
    ip = ip + 1
    if ip == instructions.size then stack(sp - 1)
    else tailcall instructions(ip)()
  }

}
case object Mul extends Op {
  def apply(): Int = {
    val a = stack(sp - 1)
    val b = stack(sp - 2)
    stack(sp - 2) = (a * b)
    sp = sp - 1
    ip = ip + 1
    if ip == instructions.size then stack(sp - 1)
    else tailcall instructions(ip)()
  }
}
case object Div extends Op {
  def apply(): Int = {
    val a = stack(sp - 1)
    val b = stack(sp - 2)
    stack(sp - 2) = (a / b)
    sp = sp - 1
    ip = ip + 1
    if ip == instructions.size then stack(sp - 1)
    else tailcall instructions(ip)()
  }
}

There is one variant left, which is to keep the instructions as bytecode data but use tail calls in instruction dispatch. This gives us indirect threaded dispatch.

val instructions: Array[ByteCode] = ???

var sp: Int = 0
var ip: Int = 0

def lit(value: Double): Int = {
  stack(sp) = value
  sp = sp + 1
  ip = ip + 1
  if ip == instructions.size then stack(sp - 1)
  else tailcall dispatch(instruction(ip))
}

def add(): Int = {
  val a = stack(sp - 1)
  val b = stack(sp - 2)
  stack(sp - 2) = (a + b)
  sp = sp - 1
  ip = ip + 1
  if ip == instructions.size then stack(sp - 1)
  else tailcall dispatch(instruction(ip))
}

def sub(): Int = {
  val a = stack(sp - 1)
  val b = stack(sp - 2)
  stack(sp - 2) = (a - b)
  sp = sp - 1
  ip = ip + 1
  if ip == instructions.size then stack(sp - 1)
  else tailcall dispatch(instruction(ip))
}

def mul(): Int = {
  val a = stack(sp - 1)
  val b = stack(sp - 2)
  stack(sp - 2) = (a * b)
  sp = sp - 1
  ip = ip + 1
  if ip == instructions.size then stack(sp - 1)
  else tailcall dispatch(instruction(ip))
}

def div(): Int = {
  val a = stack(sp - 1)
  val b = stack(sp - 2)
  stack(sp - 2) = (a / b)
  sp = sp - 1
  ip = ip + 1
  if ip == instructions.size then stack(sp - 1)
  else tailcall dispatch(instruction(ip))
}

def dispatch(instruction: ByteCode): Unit = {
  instruction match {
    case Op.Lit(value) =>
      tailcall lit(value)
    case Op.Add =>
      tailcall add()
    case Op.Sub =>
      tailcall sub()
    case Op.Mul =>
      tailcall mul()
    case Op.Div =>
      tailcall div()
  }
}

Conclusions

We’ve seen the four main variants of dispatch can all be explained by considering dualities between data and functions for instructions and calls and returns for looping:

data / call and return: switch dispatch
data / tail call: indirect threaded dispatch
function / call and return: subroutine dispatch
function / tail call: direct threaded dispatch

To me using duality to understand these different techniques is very satisfying. It means I can keep one mental model that is realized in different ways depending on the programming language features available. For example, if I have full tail calls (or some equivalent, like labels-as-values) then I can implement direct threaded dispatch. Without full tail calls, perhaps I use subroutine threaded dispatch instead (which I can view of as trampolining direct threaded dispatch, but that’s a slightly different story.) In this conceptual approach resonates with you, I encourage you to signup for the book’s newsletter, where I’m sharing copies of the second edition.

You may also wonder about performance. I’m my experiments subroutine dispatch is about sixty thousand times (yes, really) faster than switch dispatch for a very simple benchmark. If you’re interested in the code, I have a repository with all the experiments I tried. I’m still exploring these performance differences, but my best guess is that subroutine threaded dispatch is easier for the Hotspot compiler to optimize, which brings far larger performance improvements than anything that interpreter optimizations can bring. Writing an interpreter to work with a JIT compiler is itself an interesting problem, and one that seems under-explored, but that’s a topic for a different post.

Essential Effects book updated!

2024-03-14T00:00:00Z

Hi there, and happy π day!

I just finished updating “Essential Effects” to Cats Effect 3. This has been the #1 most important task for me, along with being the most important request from readers. Next I will be making the final edits while adding an additional case study.

If you’ve purchased the book already, updated copies have been sent out. If you haven’t gotten the book yet, hopefully this update will make you more interested. There’s an excerpt available if you want to take a look, containing an extra discount code. (Shh, it’s ee-ce3!)

As always, the main site is essentialeffects.dev. Let me know what you think!

Direct-style Effects Explained

2024-04-24T00:00:00Z

Direct-style effects, also known as algebraic effects and effect handlers, are the next big thing in programming languages. They are already available in Unison and OCaml, are coming to Scala, and I’m seeing discussion about them in other closely-related-to-industry contexts.

The goal is very simple: to allow us to write code in a natural style without monads, but still get the benefits of reasoning and composition that monads bring. At the same time I see some confusion about direct-style effects. In this post I want to address this confusion by explaining the what, the why, and the how of direct-style effects using a Scala 3 implementation as an example.

There is quite a bit going on here. First we’ll talk about the problem we’re trying to solve and the constraints we’re operating under. Then we’ll look at a simple implementation in Scala 3 and describe the language feature, contextual functions, that enables it. Next up we’ll see some shortcomings of this implementation and see how they can solved by two language features, one well known (delimited continuations) and one in development (type system innovations). Finally I’ll give some pointers to more about information on this topic.

What We Care About

When we argue for one programming style over alternatives we are making a value judgement about programming. It is helpful to be explicit about what those values are. As I’ve written elsewhere, I believe the core values of functional programming are reasoning and composition. Side effects stop us achieving both of these, but every useful program must interact with the world in some way. (If you’re uncertain what is meant by a side effect, this chapter of Creative Scala goes into detail.) Therefore, replacing side effects with something in keeping with these core principles is considered an important problem in functional programming. Solutions to this problem are called effect systems.

Nota bene: in this post I use the term side effect for uncontrolled effects, and just effect for effects that are controlled in a more desirable way.

Monads are the most common effect system in modern functional programming, but this doesn’t mean they are the only approach. Older versions of Haskell used streams. The Clean language uses uniqueness types, which are very closely related to the affine types seen in Rust’s borrow checker. Most current research work focuses on what are called algebraic effects and effect handlers. It’s this kind of approach we will be exploring, though we have some background to get through first.

Now we known why effect systems are interesting, let’s look at some of the design choices in effect systems.

The Design Space of Effect Systems

Reasoning and composition are non-negotiable criteria for any effect system. There are other criteria that are desirable, however. Here we will look at the style in which code is written, the separation between description and action, and some of the nuances in how effect systems can help us reason about and compose effectful code.

Direct and Monadic Style

The style of code that we have to write to use the effect system is a major determinant of how usable the system is. If an effect system requires too much work from the programmer it is unusable in practice, no matter what other properties it has. Here we will look at direct style, which is code as we want to write it, and monadic style, which is code as monadic effect systems force us to write it.

Direct style code is code as it is usually written. You call functions, they return results, and you use those results in further computations. Here’s the kind of code we write in direct style.

val a: A = ???
val b = doSomething(a)
val c = doSomething2(b)
val d = doSomething3(c)

We don’t need to say much about direct style, other than that it is desirable to write in this style.

As most Scala programmers will have experienced, we must write code in a different style if we are to use monads. In monadic style the code above ends up looking something like

doSomething(a)
  .flatMap(b => doSomething(b))
  .flatMap(c => doSomething(c))

This is considered annoying enough that languages that support monads usually provide special syntax for them. In Scala we can write

for {
  b <- doSomething(a)
  c <- doSomething(b)
  d <- doSomething(c)
} yield d

This isn’t too bad. Lots of developers have written code like this. However, it’s still a different style of coding that has been learned, and hence a barrier to entry. It’s also a whole program transform. Once one part of our code start using monads, it is usually the case that all of our code has to be transformed to monadic style. So ideally an alternative effect system would allow us to continue to write in direct style.

Description and Action

Any effect system must have a separation between describing the effects that should occur, and actually carrying out those effects. This is a requirement of composition. Consider perhaps the simplest effect in any programming language: printing to the console. In Scala we can accomplish this as a side effect with println:

println("OMG, it's an effect")

Imagine we want to compose the effect of printing to the console with the effect that changes the color of the text on the console. With the println side effect we cannot do this. Once we call println the output is already printed; there is no opportunity to change the color.

Let me be clear that the goal is composition. We can certainly use two side effects that happen to occur in the correct order to get the output with the color we want.

println("\u001b[91m") // Color code for bright red text
println("OMG, it's an effect")

However this is not the same thing as composing an effect that combines these two effects. For example, the example above doesn’t reset the foreground color so all subsequent output will be bright red. This is the classic problem of side effects: they have “action at a distance” meaning one part of the program can change the meaning of another part of the program. This in turns means we cannot reason locally, nor can we build programs in a compositional way.

What we really want is to write code like

Effect.println("OMG, it's an effect").foregroundBrightRed

which limits the foreground colour to just the given text. We can only do if we have a separation between describing the effect, as we have done above, and actually running it.

Reasoning and Composing with Effects

Effect systems should help us reason about what code does. Take for example, the following method signature:

def cthulhuFhtagn(): Unit

What happens when we call this method? Returning Unit suggests it has some side-effect, but what is that side-effect? It could print to the console, raise an exception, or wake a Great Old One to destroy the Earth. We cannot tell.

Using the IO monad is similar. If we instead see the method signature

def cthulhuFhtagn(): IO[Unit]

we again don’t know what effects will occur but we do have some way to manipulate those effects. We can attempt to cancel the effects, for example, by writing

IO.canceled *> cthulhuFhtagn()

or instead recover from errors using handleError.

It’s important to note that we can do this manipulation of effects in a composable way. For instance, we can pass the IO to some other method that chooses how to manipulate it.

def cancelOrRecover(effect: IO[Unit]): IO[Unit] =
  // Continue only if the stars are right
  IO.realTimeInstant
    .map(time => starsAreRight(time))
    .ifM(
      true = effect.handleError(...),
      false = IO.cancel *> effect 
    )
    
cancelOrRecover(cthulhuFhtagn())

We cannot do this in the first case that uses side-effects.

Before we get into effect systems, there another issue I want to quickly deal with, which is composition of effects. One criticism of IO is that it lumps all effects into one type. We might want to be more precise, and say, for example, this method requires logging and database access, while that method reads from the keyboard and prints to the screen. Monad transformers are one way to achieve this, but they are difficult to use. A more common alternative is tagless final. The method signature

def cthulhuFhtagn[F[_]: WakeGreatOldOne](): F[Unit]

indicates this method requires a WakeGreatOldOne effect, which we might use to decide to not call the method. Tagless final is also inconvenient, but not so inconvenient to stop it becoming relatively common in the Scala world.

Direct-style Effect Systems in Scala 3

Let’s now implement a direct-style effect system in Scala 3. This requires some machinery that is new in Scala 3. Since that’s probably unfamiliar to many readers we’re going to start with an example, explain the programming techniques behind it, and then explain the concepts it embodies.

Our example is a simple effect system for printing to the console. The implementation is below. You can save this in a file (called, say, Print.scala) and run it with scala-cli with the command scala-cli Print.scala.

//> using scala 3

// For convenience, so we don't have to write Console.type everywhere.
type Console = Console.type

type Print[A] = Console ?=> A
extension [A](print: Print[A]) {

  /** Insert a prefix before `print` */
  def prefix(first: Print[Unit]): Print[A] =
    Print {
      first
      print
    }

  /** Use red foreground color when printing */
  def red: Print[A] =
    Print {
      Print.print(Console.RED)
      val result = print
      Print.print(Console.RESET)
      result
    }
}
object Print {
  def print(msg: Any)(using c: Console): Unit =
    c.print(msg)

  def println(msg: Any)(using c: Console): Unit =
    c.println(msg)

  def run[A](print: Print[A]): A = {
    given c: Console = Console
    print
  }

  /** Constructor for `Print` values */
  inline def apply[A](inline body: Console ?=> A): Print[A] =
    body
}

@main def go(): Unit = {
  // Declare some `Prints`
  val message: Print[Unit] =
    Print.println("Hello from direct-style land!")

  // Composition
  val red: Print[Unit] =
    Print.println("Amazing!").prefix(Print.print("> ").red)

  // Make some output
  Print.run(message)
  Print.run(red)
}

A Print[A] is a description: a program that when run may print to the console and also compute a value of type A. It is implemented as a context function. You can think of a context function as a normal function with given (implicit) parameters. In our case a Print[A] is a context function with a Console given parameter. (Console is a type in the Scala standard library.)

Context function types have a special rule that makes constructing them easier: a normal expression will be converted to an expression that produces a context function if the type of the expression is a context function. Let’s unpack that by seeing how it works in practice. In the example above we have the line

val message: Print[Unit] =
  Print.println("Hello from direct-style land!")

Print.println is an expression with type Unit, not a context function type. However Print[Unit] is a context function type. This type annotation causes Print.println to be converted to a context function type. You can check this yourself by removing the type annotation:

val message =
  Print.println("Hello from direct-style land!")

This will not compile.

We use the same trick with Print.apply, which is a general purpose constructor. You can call apply with any expression and it will be converted to a context function. (As far as I know it is not essential to use inline, but all the examples I learned from do this so I do it as well. I assume it is an optimization.)

Running a Print[A] uses another bit of special sauce: if there is given value of the correct type in scope of a context function, that given value will be automatically applied to the function. This is also what makes direct-style composition, an example of which is shown below, work. The calls to Print.print are in a context where a Console is available, and so will be evaluated once the surrounding context function is run.

def red: Print[A] =
  Print {
    Print.print(Console.RED)
    val result = print
    Print.print(Console.RESET)
    result
  }

That’s the mechanics of how direct-style effect systems work in Scala: it all comes down to context functions.

Notice what we have in these examples: we write code in the natural direct style, but we still have an informative type, Print[A], that helps us reason about effects and we can compose together values of type Print[A].

I’m going to deal with composition of different effects and more in just a bit. First though, I want describe the concepts behind what we’ve done.

Notice in direct-style effects we split effects into two parts: context functions that define the effects we need, and the actual implementation of those effects. In the literature these are called algebraic effects and effect handlers respectively. This is an important difference from IO, where the same type indicates the need for effects and provides the implementation of those effects.

Also notice that we use the argument type of context functions to indicate the effects we need, rather the result type as in monadic effects. This difference avoids the “colored function” problem with monads. We can think of the arguments as specifying requirements on the environment or context in which the context functions, hence the name.

Now let’s look at composition of effects, and effects that modify control flow.

Composition of Direct-Style Effects

Direct-style effects compose in a straightforward way: we just add additional parameters to our context function. Here’s a simple example that defines another effect, Sample, for producing random values, and then builds a program that requires both Print and Sample.

First we define the effect, using the same pattern as before.

import scala.util.Random

// A `Sample[A]` is a description of an effect that, when run, will generate a
// values of type `A` possibly using a random number generator
type Sample[A] = Random ?=> A
object Sample {
  // This runs a `Sample[A]` producing a value of type `A`. By default it uses
  // the global random number generator, but the user can pass in a different
  // generator as the first argument.
  def run[A](sample: Sample[A])(using random: Random = scala.util.Random): A = {
    given r: Random = random
    sample
  }

  // Utility to use inside a `Sample[A]` to produce a random `Int`
  def int(using r: Random): Int =
    r.nextInt()

  // Utility to use inside a `Sample[A]` to produce a random `Double`
  def double(using r: Random): Double =
    r.nextDouble()

  // Constructs a `Sample[A]`.
  inline def apply[A](inline body: Random ?=> A): Sample[A] =
    body
}

Now we can use both Print and Sample.

val printSample: (Console, Random) ?=> Unit =
  Print {
    val i = Sample { Sample.int }
    Print.println(i)
  }

Print.run(Sample.run(printSample))

Effects That Change Control Flow

So far, the effects we’ve looked at have very simple control flow. In fact they don’t alter the control flow at all. Many interesting effects, such as error handling and concurrency, require manipulation of the program’s control flow. How do we handle this in our model?

We need a slight extension to accomodate this: when the user program calls an effect handler method, the effect handler is passed not just that method’s arguments but also also a continuation that it can resume when the effect is complete. What’s a continuation? It represents the “rest of the program”: a value that can be invoked to continue execution from the point that called the effect handler. Cooperative threads, fibers, generators, and coroutines are all examples of abstractions that use a form of continuations.

Continuations can be implemented as a program transform, but for performance we ideally want runtime support. This is why Scala Native is getting continuations. On the JVM, Project Loom adds them.

Scala 3 does not yet expose a continuation API, but it does have non-local exits in scala.util.boundary that can express a few interesting things. Here’s an example implementing error-handling in the style of exceptions.

//> using scala 3

import scala.util.boundary
import scala.util.boundary.{break, Label}

final class Error[-A](using label: Label[A]) {
  def raise(error: A): Nothing =
    break(error)
}

type Raise[A] = Error[A] ?=> A
object Raise {
  inline def apply[A](inline body: Error[A] ?=> A): Raise[A] =
    body

  def raise[A](error: A)(using e: Error[A]): Nothing =
    e.raise(error)

  def run[A](raise: Raise[A]): A = {
    boundary[A] {
      given error: Error[A] = new Error[A]
      raise
    }
  }
}

@main def go(): Unit = {
  val program: Raise[String] =
    Raise {
      // This early return is difficult to write in a purely functional style
      List(1, 2, 3, 4)
        .foreach(x => if x == 3 then Raise.raise("Found 3"))
      "No 3 found"
    }

  val result = Raise.run(program)
  println(result)
}

Notice that we still have the separation between description and action. The program isn’t run until we call Raise.run, and the control-flow exits at the point where it is run, not at the point where it is defined.

Using direct-style effects we can write programs that would have to use traverse or other combinators in monadic style. Here’s an example that produces an Option[List[Int]] from a List[Int].

val traverse: Raise[Option[List[Int]]] =
  Raise {
    Some(
      List(1, 2, 3, 4).map(x => if x == 3 then Raise.raise(None) else x)
    )
  }
println(Raise.run(traverse))

This is the equivalent of the following program using Cats:

val traverseCats: Option[List[Int]] =
  List(1, 2, 3, 4).traverse(x => if x == 3 then None else Some(x))

You might wonder how monads implement effects that play with control flow without requiring runtime support. The answer is that monads require the user to explicitly specify the control-flow. This is exactly what flatMap does: it expresses what should happen in what order, and by giving the monad this information as a chain of flatMaps it can evaluate them in the order that makes sense for the particular monad implementation. In fact monads are equivalent to delimited continuations. So direct-style effects and monad effects can be seen as just two different syntaxes for writing the same thing.

Capturing, Types, and Effects

What we’ve seen so far suggests that effects are straightforward to implement and use, and they are for the most part. However there is at least one wrinkle that we need to be aware of: capturing effects.

In the following code we capture a Error[String] in a closure, and then attempt to call the raise method on that Error outside of the block where it is valid. This leads to a runtime exception.

val capture: Raise[() => String] =
  Raise { error ?=> () =>
    if 3 < 2 then "Nothing to see here"
    else Raise.raise(() => "Hahahahaha!")(using error)
  }

val closure = Raise.run(capture)
println(closure())

Is this a serious flaw in the entire foundation of direct-style effects? No! What we’ve seen so far is only the portion of the effect system that is currently in Scala 3. Capture checking, which is still experimental, rules out this kind of bug. The Capturing Types paper has all the technical details.

Capture checking in fact goes further than the examples we’ve seen so far. It tracks capability usage in the dynamic scope of the program. It can be used to implement composition of different effects. We saw an example earlier where we constructed a context function with type (Console, Random) ?=> Unit. You might have given this type a bit of side-eye as it doesn’t use the type aliases we used for the two effects on their own (Print and Sample.) With capture checking the type system works out these types for us. It can also be use for resource checking, such as ensuring all open files are closed or that region-based memory management is implemented without leaks.

Conclusions and Further Reading

We’ve seen that direct-style effect allow us to write code in a natural direct style, while still retaining useful types that help with reasoning and allowing composition of effects. The implementation is a combination of:

context functions;
continuations; and
type system improvements

which together allow us to express effects in direct-style as operations on effect handlers.

Overall, I’m pretty excited by direct-style effects in general, and direct-style effects in Scala in particular. I think they are much more ergonomic than monadic effects, which in turn makes them accessible to a wider range of programmers. I’m also excited to have access to continuations, and presumably tail calls, in more languages. Tail calls are really useful for certain problems, such as virtual machine dispatch.

I’m also excited to see Scala continuing to evolve. Scala has always been a language of innovation, and these changes are nothing more than a continuation (pun-intended) of that heritage. I’m also excited to see more investment in Scala Native. I think it’s only in Scala Native that the developers will have the flexibility to implement the runtime support needed for a full effect system, and also to really maximise its advantages by providing things like region based memory management. I also think Scala Native is important for Scala’s industrial adoption in use cases like serverless, so I see more investment in Scala Native as a big win for the community.

If you’d like to read more about direct-style effects here are some suggestions, which are a mix of accessible introductions and academic papers:

Abilities for the monadically inclined, a very nice post from the Unison team that covers a lot of the same material from a different perspective.
Dean Wampler’s post What is “Direct Style”.
The Gears concurrency library being developed for Scala 3.
Raise4s, a simple example of error handling as a direct-style effect.
An Introduction to Algebraic Effects and Handlers is a tutorial from a more theoretic perspective.
Handlers in Action is one of the more readable academic papers on implementing effect handlers.
Capturing Types describes the extensions to the Scala type system that are necessary for correctly implementing effects.

Finally, if you’ve found this interesting I think you’ll love my book, Functional Programming Strategies. It covers lots of the concepts in this post, such as continuation-passing style and interpreters, and a whole lot more.

Inner Product

How to Write an Abstract

Solving the Rubik's Cube with Group Theory and Functional Programming

Introduction

Overview of topics covered

Permutations

Group Theory

Functional Programming

List of Articles:

Permutations as Functions

Scrambles of a String

Bijections from a Set to Itself

Implementing Permutations with Map[A, A]

The Group Typeclass

An Intuition for Monoids and Groups

Semigroups and Monoids

Semigroup

Monoid

Group: Monoid with Inverse

Permutation Groups

Example: Permutations of Three Elements

Tips for Teaching Scala

Notional Machines

Programming Strategies

More Than Code

Shut Up

Peer Learning

Further Resources

Conclusions

Type Classes vs Records of Functions

A Who of What?

Composition

Comprehensibility

Multiple Instances

Convenience

Summary

Optional Actions

The Basic Scenario

Avoiding Unexamined Effects

Optional Actions via the Option type

Conclusions

Leveraging Monoids for More Powerful Summarization

Decomposing Summarization

Capturing Common Behavior in a Typeclass

Deriving foldMap

Computing the Mean with foldMap

Computing the Mean with foldMap: Improved!

Summary

Inner Product's Best of 2019

Talks

Intro to Cats-Effect, Gavin Bisesi

Performance Matters, Emery Berger

Scale By The Bay 2019: Paul Cleary, Re-programming the programmer, from Actors to FP, Paul Cleary

Probabilistic scripts for automating common-sense tasks, Alexander Lew

Finding bugs without running or even looking at code, Jay Parlar

Videos

The “real programmer” myth, Maciek Gorywoda

NaN Gates and Flip FLOPS, Tom 7

Writing

Parse, don’t validate, Alexis King

Yes! and …, Tom Critchlow

Using a hard disk as a listening device, Andrew Kwong, Wenyuan Xu, and Kevin Fu

Other Recommendations

ScalaBridge London

LSE Podcasts

The Unison language

Creative Coding

Turtles in Minecraft

For all the Family

Building Serverless Scala Services with GraalVM

Why Native Image?

Overview of the Process

Installing GraalVM

Writing the Code

GraalVM Configuration

Cross-Building Using Docker

Creating a Deployment Docker Image

Conclusions

Acknowledgements

Benchmarking Web Services using GraalVM Native Image

Implementing Permutations with `Map[A, A]`

Optional Actions via the `Option` type

Deriving `foldMap`

Computing the Mean with `foldMap`

Computing the Mean with `foldMap`: Improved!

Example: Is `Option` an Effect?

Example: Is `Future` an Effect?

A simple `MyIO` data type

`MyIO` as an Effect

What does `Functor.widen` do?

How is `Functor.widen` implemented?

What is this `<:<` type?

Using a `<:<` value

Back to `Functor.widen`