This is a really cool thing in TypeScript I’ve been exploring recently. It turns out you can make subtypes without any extra libraries or tools! And the code to do it is really easy.

Imagine you could finally have types for positive integers or non-empty strings where you need them:

type PositiveInteger = ???
type NonEmptyString = ???

type Product = {
  name: NonEmptyString
  description: string
  priceCents: PositiveInteger
}

const addToCart = (product: Product, quantity: PositiveInteger, cart: Cart) => Cart {
  // add a product, not having to worry about the quantity being a negative number or 0
}

Then you wouldn’t have to handle weird edge-cases like a product with an empty name, or a quantity that’s fractional or negative.

You could even strictly accept pre-validated parameters:

type ValidName = ???
type ValidBirthYear = ???

// This function will only accept a valid name and birth year.
const register = (name: ValidName, birthYear: ValidBirthYear): void => {
  console.log(`Registering user "${name}" born in ${birthYear}.`)
}

What are subtypes?

In simple terms, a subtype is when you narrow down a type to be more specific.

In logical terms, B is a subtype of A when all Bs are As. For example, all cats are mammals. So, Cat is a subtype of Mammal. And Mammal is a subtype of Animal. Prime number is a subtype of Natural number. You get the picture.

You can think of making a subtype of type A by choosing a certain property that some As may have. This means B is a subtype of A defined by some predicate over A. In other words, any value of type A can be of type B if it has that chosen property. If this sounds complicated, don’t worry—it will make more sense in a moment.

✨ The code ✨

Subtype: Positive Number

Starting with an example, this is how you can make a subtype for positive numbers:

type A = number
type PositiveNumber = A & { readonly __type: unique symbol }

const isPositiveNumber = (x: A): x is PositiveNumber => {
  return x >= 1
}

const x: A = 2
if (isPositiveNumber(x)) {
  const y: PositiveNumber = x
  console.log('y:', y)
}

Looks weird, right? I’ll break it down line by line.

type A = number

You don’t really need this line; I added it for clarity. This is just making A a type alias for number. When you’re making a subtype of some custom type (instead of a primitive type), A would be that custom type.

type PositiveNumber = A & { readonly __type: unique symbol }

This is the weirdest line you have to write. This makes a new type PositiveNumber, defined as the type A along with a new property with a unique symbol. Everything about the added property is to prevent you from being able to make a value of type PositiveNumber directly, while retaining the original properties of type A.¹ You don’t need to worry about exactly how this works. The cool thing is, this line doesn’t change! Anytime you make a subtype, you can write this line the same way (substituting A for the (super)type of your choice). Notice that this line doesn’t actually say anything about what a positive number is; it just gives the subtype a name. This line should always be paired with a predicate function:

const isPositiveNumber = (x: A): x is PositiveNumber => {
  return x >= 1
}

This is where the meaning of PositiveNumber is actually defined. More than that, without this function, you can’t even make a PositiveNumber value!² This is using TypeScript’s feature of type predicates. You can think of this function as returning a normal boolean value, though TypeScript gives it special treatment that brings this all together:

const x: A = 2
if (isPositiveNumber(x)) {
  const y: PositiveNumber = x
  console.log('y:', y)
}

This is where things get really interesting. Like I said, the only way to make a PositiveNumber value is to invoke the isPositiveNumber predicate function on some value x of type A. And the only place where TypeScript will accept that you can actually have a PositiveNumber value is in the scope where isPositiveNumber(x) returned true. The way I think of it, you need to use the predicate function to provide a proof that you have a value of your subtype. After all, your subtype is defined by that predicate. So in this code, y is allowed to be of type PositiveNumber if you set it to x in scope of where isPositiveNumber(x) returned true.

Shorter Version

In practice, I would write and use the PositiveNumber subtype a little differently:

type PositiveNumber = number & { readonly __type: unique symbol }

const isPositiveNumber = (x: A): x is PositiveNumber => {
  return x >= 1
}

const x: A = 2
if (isPositiveNumber(x)) {
  console.log('x:', x)
}

All I’ve done is remove the superfluous A type alias and the y variable. In the scope where x has been proven to be a positive number, x itself can be of type PositiveNumber. In fact, x can be treated as being a number or a PositiveNumber within that context.

General Subtype Template

The general structure for making and using a subtype looks like this:

type A = {} // some specific type
type B = A & { readonly __type: unique symbol }

const isB = (x: A): x is B => {
  // return a boolean value
  return true
}

const x: A = {} // some value of type A
if (isB(x)) {
  const y: B = x
  console.log('y:', y)
}

Why does this matter?

If you’re not yet convinced of the usefulness of subtypes, reflect on why you’re using TypeScript in the first place: you want to have a type checker catch any obvious mistakes during compile-time as opposed to you discovering them later during runtime. You want to make sure the data you’re working with conforms to the types you’ve decided it should. Why not extend that notion to even more useful types? Do you really think a general number type is the best case for any numeric scenario? Surely a non-negative number or a whole number would be better for many cases.

And if you’re still not convinced, maybe the next two sections will change your mind.

You can test subtypes!

Maybe you’re worried your predicate function doesn’t define your subtype correctly. Not a problem! You can always treat the predicate function as if it returns a normal boolean and write tests for it.

type ValidBirthYear = number & { readonly __type: unique symbol }

const isValidBirthYear = (year: number): year is ValidBirthYear => {
  const thisYear: number = new Date().getFullYear()
  return year >= 1900 && year <= thisYear
}

console.log('Tests for ValidBirthYear:')
console.log(isValidBirthYear(1900))
console.log(!isValidBirthYear(1800))
console.log(isValidBirthYear(2023))
console.log(!isValidBirthYear(2100))

More examples

I want to finish off with a bunch of pragmatic examples to show some different ways of how you might use subtypes in your own projects.

NonNegativeInteger

type NonNegativeInteger = number & { readonly __type: unique symbol }

const isNonNegativeInteger = (x: number): x is NonNegativeInteger => {
  return !(x < 0) && Math.floor(x) === x
}

const betterRepeat = (s: string, n: NonNegativeInteger): string => {
  return s.repeat(n)
}

const ex1: number = 3
if (isNonNegativeInteger(ex1)) {
  // This will run.
  console.log(betterRepeat('hello', ex1))
}

const ex2: number = 3.1
if (isNonNegativeInteger(ex2)) {
  // This won't run.
  console.log(betterRepeat('hello', ex2))
}

const ex3: number = -3
if (isNonNegativeInteger(ex3)) {
  // This won't run.
  console.log(betterRepeat('hello', ex3))
}

In the third example usage, where ex3 is -3, normally giving a negative number to the String.prototype.repeat() function would produce a runtime error. Instead, we caught it in compile-time and prevented it from happening at all!

NonEmptyArray

Non-empty arrays are very useful in functional programming.

Normally, functions like head() and last() would return undefined when given an empty array, breaking the type rules:

const head = <T>(xs: Array<T>): T => xs[0]
const last = <T>(xs: Array<T>): T => xs[xs.length - 1]

const arrEmpty: Array<number> = []
console.log('head(arrEmpty):', head(arrEmpty)) // undefined
console.log('last(arrEmpty):', last(arrEmpty)) // undefined

We can make better versions with a NonEmptyArray subtype:

type NonEmptyArray<T> = Array<T> & { readonly __type: unique symbol }

const isNonEmptyArray = <T>(xs: Array<T>): xs is NonEmptyArray<T> => {
  return xs.length >= 1
}

const head = <T>(xs: NonEmptyArray<T>): T => xs[0]
const last = <T>(xs: NonEmptyArray<T>): T => xs[xs.length - 1]

const arr1: Array<number> = [1]
const arrEmpty: Array<number> = []

if (isNonEmptyArray(arr1)) {
  console.log('head(arr1):', head(arr1))
  console.log('last(arr1):', last(arr1))
}

if (isNonEmptyArray(arrEmpty)) {
  // None of this will run.
  console.log('head(arrEmpty):', head(arrEmpty))
  console.log('last(arrEmpty):', last(arrEmpty))
}

ValidWardrobe³

I like this example because it shows how far you can stretch the predicate function. Which, it turns out, is as far as you want! As long as it returns a boolean in the end, you’re good.

type Colour = 'white' | 'cream' | 'blue' | 'navy' // ...

type Wardrobe = {
  owner: {
    name: string
    age: number
  }
  tops: Colour[]
  pants: Colour[]
  shorts: Colour[]
  skirts: Colour[]
  desiredNumberOfOutfits: number
}

type ValidWardrobe = Wardrobe & { readonly __type: unique symbol }

const isValidWardrobe = (wardrobe: Wardrobe): wardrobe is ValidWardrobe => {
  const numOutfits: number =
    wardrobe.tops.length * wardrobe.pants.length
    + wardrobe.tops.length * wardrobe.shorts.length
    + wardrobe.tops.length * wardrobe.skirts.length

  return numOutfits >= wardrobe.desiredNumberOfOutfits
}

const suggestOutfits = (wardrobe: ValidWardrobe): void => {
  console.log(`Printing suggested outfits for ${wardrobe.owner.name}...`)
  // Do stuff here, knowing that wardrobe has already been validated.
}

const ex1: Wardrobe = {
  owner: {
    name: 'Alice',
    age: 22
  },
  tops: ['blue', 'white', 'cream'],
  pants: ['navy', 'blue'],
  shorts: ['navy'],
  skirts: ['navy', 'blue'],
  desiredNumberOfOutfits: 15
}
if (isValidWardrobe(ex1)) {
  suggestOutfits(ex1)
}

Validated Form Input

Let’s say you have some input from a user registration form. And you have a register function whose job is to save this user data somewhere. Rather than clouding the concerns of register by validating the user data within the function, you can have it only accept data that has been previously validated!

type ValidName = string & { readonly __type: unique symbol }
const isValidName = (name: string): name is ValidName => name.trim().length > 0

type ValidBirthYear = number & { readonly __type: unique symbol }
const isValidBirthYear = (year: number): year is ValidBirthYear => {
  const thisYear: number = new Date().getFullYear()
  return year >= 1900 && year <= thisYear
}

const register = (name: ValidName, birthYear: ValidBirthYear): void => {
  console.log(`Registering user with name "${name}" born in ${birthYear}`)
}

const nameInput: string = 'test'
const birthYearInput: number = 1800

if (!isValidName(nameInput)) {
  console.log('Name cannot be empty')
} else if (!isValidBirthYear(birthYearInput)) {
  console.log('Invalid birth year')
} else {
  register(nameInput, birthYearInput)
}

PositiveInteger, NonEmptyString

You can nest subtypes in other types, too.

type PositiveInteger = number & { readonly __type: unique symbol }

const isPositiveInteger = (x: number): x is PositiveInteger => {
  return x >= 1 && Math.floor(x) === x
}

type NonEmptyString = string & { readonly __type: unique symbol }

const isNonEmptyString = (s: string): s is NonEmptyString => {
  return s.trim().length > 0
}

type Product = {
  name: NonEmptyString
  description: string
  priceCents: PositiveInteger
}

type Cart = {} // Use your imagination

const addToCart = (product: Product, quantity: PositiveInteger, cart: Cart): Cart => {
  // Add a product to the cart, not having to worry about the quantity being a negative number or 0.
  // ...

  return cart
}

Footnotes

Did you know it’s not recommended to learn how to ride a bicycle using training wheels anymore?¹ It’s true!² What people found is that using training wheels don’t enable the rider to learn the crucial skill of balancing on a bicycle. So, while training wheels do lower the stakes when falling, they also remove the activity’s essential components.

As a teacher, I’ve noticed the same sort of problem can come up with people learning to code. The problem is, if you learn with “training wheels” on, at some point you have to take them off. And that can be a rough transition. And, if you don’t know you’re using training wheels in your learning, you may not even know what skills you’re missing out on.

What do I mean by “training wheels” in learning to code? Well, they can come in different forms:

• Online editors
• Custom libraries, frameworks, or languages designed for teaching
• Code-along video tutorials

For example, the ever-popular site freeCodeCamp provides coding lessons paired with a custom-built online editor. That means you’re typing code in a sandbox environment. If you make a mistake in your code, you’re given a kind of error message that’s different from anything a professional developer would see. You’re also not able to experiment and try things that you would be able to do if you simply ran your code on your own computer, which is a huge part of being a programmer! Now, I’m not saying freeCodeCamp is bad, but you should be aware that this is a very different environment than any practicing developer uses. On freeCodeCamp, you’re having your hand held so tightly that you can’t find your balance on your own.

What I find is, by the end of a student taking a course with a sandbox environment, they’re lost as to how to code on their own computer. They don’t know how to set up a project, how to debug their code when things go wrong, or how to share their finished app with other people. These are all essential skills for any developer.

The story is similar when a student learns to code using a custom library, framework, or language. After they’re finished the course, they don’t know where the course’s custom material ends and the stuff they can use in the real world begins. With frustration, they ask themselves, “How do I make an app without using the course tools?”

When it comes to code-along video tutorials, you’re not free to make your own mistakes. So you never really get a sense of what to do when things go wrong. Believe me, in programming, things go wrong all the time. That’s part of the fun! Figuring out what went wrong and why it’s happening, then solving the problem is one of the biggest and best parts of programming. If you’re just copying down someone else’s thoughts, you’re not learning how to think on your own.

Now, I’m not saying this to discourage readers from using certain resources. I just think you should be aware of when you’re using training wheels and whether there may be a better option.

When I wrote Intuitive JavaScript, I purposefully left the exercises as plain *.js files to encourage the student to save the code and run their solutions on their own computer. This is closer to how a professional developer works. Getting used to the tools of the industry, like Visual Studio Code and Node.js, is essential for anyone who wants to become a working developer, and probably easier than you think!

Footnotes

Overview

In my previous post, I described how to build a genetic algorithm in any programming language. Here, I want to give an example of a complete implementation in TypeScript. This is a brain dump style of post—just something to give you an idea of how I approach solving this problem. I have to admit, it’s not entirely accurate because I’m not including all the mistakes and backtracking along the way. Since this is a written post, and not a video, it makes it seem like my process is linear when it really isn’t. I would normally create functions with gaps to be filled, going back and forth between them a lot.

Also important to note is that standard JavaScript/TypeScript is lacking in basic utility functions, so I will be making references to useful generic functions that I put in a separate module (util.ts).

If you want to skip this post and just see the code (with comments), here’s a link to the repo:

https://github.com/SlimTim10/genetic-algorithm-math-string

Problem

Given a target number, find a string of single-digit numbers and basic arithmetic operators that equals that number. For example, if the target number is 10, some solutions would be:

• 5 + 5
• 5 * 2
• 5 + 5 + 1 - 1 - 5 - 5 + 1 + 9 * 1 / 1

The strings will be evaluated using the standard order of operations. So, 2 + 2 * 3 = 8.

Implementation

See my previous post for a detailed plan that serves as the basis for this implementation.

Implementing Step 1. Planning

I like to start by planning the essential pieces in terms of types.

Going from big to small…

An organism is made up of one chromosome and has a fitness number.

type Organism = {
  chromosome: Chromosome;
  fitness: number;
};

A chromosome is a collection of genes, so I’m going to make it an array. I could define it as a tuple of genes if I wanted to hard-code the length of each chromosome, but I want their length to be variable so I can tweak it on different runs of the algorithm.

type Chromosome = Gene[];

A gene is a container for information. For my implementation, I’ve decided that every gene can either be a number gene or an operator gene. So I’m going to use a union type.

type Gene = NumberGene | OperatorGene;

For the number genes, I can use four bits to represent any single-digit number (0 through 9), with a few junk alleles left over.

type NumberGene = [Bit, Bit, Bit, Bit];

For the four basic math operators (+, -, *, /), I only need two bits.

type OperatorGene = [Bit, Bit];

A bit, of course, is either 1 or 0.

type Bit = 0 | 1;

I’m going to encode all the possible number alleles for the digits 0 through 9. This way, for any gene I’m working with, I can check what its allele represents.

const numberAlleles: NumberGene[] = [
  [0, 0, 0, 0], // 0
  [0, 0, 0, 1], // 1
  [0, 0, 1, 0], // 2
  [0, 0, 1, 1], // 3
  [0, 1, 0, 0], // 4
  [0, 1, 0, 1], // 5
  [0, 1, 1, 0], // 6
  [0, 1, 1, 1], // 7
  [1, 0, 0, 0], // 8
  [1, 0, 0, 1], // 9
];

And the same for operators.

const operatorAlleles: OperatorGene[] = [
  [0, 0], // +
  [0, 1], // -
  [1, 0], // *
  [1, 1], // /
];

Now I can make a function to convert any gene to its corresponding value. For this, I’ll collect all the possible values with a union type and make a function that takes a gene and returns its represented value.

type Value
  = "0"
  | "1"
  | "2"
  | "3"
  | "4"
  | "5"
  | "6"
  | "7"
  | "8"
  | "9"
  | "+"
  | "-"
  | "*"
  | "/"
  | "(junk)";

// Predicate for number genes.
const isNumber = (gene: Gene): gene is NumberGene => {
  return numberAlleles.some((x: NumberGene) => eqArrays(x, gene));
};

// Predicate for operator genes.
const isOperator = (gene: Gene): gene is OperatorGene => {
  return operatorAlleles.some((x: OperatorGene) => eqArrays(x, gene));
};

// Take a gene and return its represented value.
const geneValue = (gene: Gene): Value => {
  // Numbers
  if (isNumber(gene)) {
    if (eqArrays(gene, [0, 0, 0, 0])) return "0";
    if (eqArrays(gene, [0, 0, 0, 1])) return "1";
    if (eqArrays(gene, [0, 0, 1, 0])) return "2";
    if (eqArrays(gene, [0, 0, 1, 1])) return "3";
    if (eqArrays(gene, [0, 1, 0, 0])) return "4";
    if (eqArrays(gene, [0, 1, 0, 1])) return "5";
    if (eqArrays(gene, [0, 1, 1, 0])) return "6";
    if (eqArrays(gene, [0, 1, 1, 1])) return "7";
    if (eqArrays(gene, [1, 0, 0, 0])) return "8";
    if (eqArrays(gene, [1, 0, 0, 1])) return "9";
  }

  // Operators
  if (isOperator(gene)) {
    if (eqArrays(gene, [0, 0])) return "+";
    if (eqArrays(gene, [0, 1])) return "-";
    if (eqArrays(gene, [1, 0])) return "*";
    if (eqArrays(gene, [1, 1])) return "/";
  }

  // Any other value is junk
  return "(junk)";
};

And now I have all the pieces needed to get an organism’s phenotype. With a function that takes in an organism, I can convert each gene to its value and join them into a space-separated string.

const phenotype = (organism: Organism): string => {
  return organism.chromosome
    .map(geneValue)
    .join(" ");
};

Since a phenotype can contain junk, I also want a way to get an organism’s cleaned-up phenotype, which will be safe to evaluate. That means I first need a way to clean the genes of a chromosome, in accordance with the plan: remove any junk genes along with their immediately preceeding gene.

const cleanChromosome = (chromosome: Chromosome): Chromosome => {
  // Add a "plus" gene to the beginning so I can deal with pairs safely.
  const genes: Gene[] = [ [0, 0], ...chromosome];
  const pairs = chunksOf(2, genes);
  return pairs
    .filter(pair => pair.length === 2)
    .filter(([_, num]) => geneValue(num) !== "(junk)")
    .reduce((acc, pair) => [...acc, ...pair], [])
    .slice(1); // Remove the initial "plus" gene.
};

And now, I can easily apply the chromosome cleaning operation to an organism as a whole.

const cleanPhenotype = (organism: Organism): string => {
  return phenotype({
    ...organism,
    chromosome: cleanChromosome(organism.chromosome)
  });
};

To evaluate the phenotype of an organism as a math string, I’m going to take the easy route and use the built-in eval function, with the assumption that the string is already cleaned. But I need to be careful here! For one, I need to be aware that using this evaluation method means the standard order of operations is being applied. That’s what I want, so that’s fine. But also, it’s possible for the result to be NaN or Infinity if a division by 0 happens. I’ll have to remember to handle these special cases when doing fitness evaluation.

const evaluateMath = (mathStr: string): number => Number(eval(mathStr));

Now to evaluate the fitness of an organism. This part is a bit tricky because I want organisms to have their fitness stored as part of their data. If an organism is a chromosome along with fitness, I can’t have my fitness evaluating function take in an organism. I need to deal with chromosomes directly. The resulting fitness score will be a number between 0 and 1, with 1 being perfect fitness. I can combine a chromosome and its fitness score into an organism somewhere else.

const evaluateFitness = (chromosome: Chromosome, target: number): number => {
  const mathStr = cleanChromosome(chromosome)
    .map(geneValue)
    .join(" ");
  const n = evaluateMath(mathStr);

  if (isNaN(n) || n === Infinity) {
    // This is as far from the target number as it can be, so let's just say the fitness is 0.
    return 0;
  } else {
    return 1 / (Math.abs(target - n) + 1);
  }
};

Implementing Step 2. Setting parameters

For running the algorithm, I’m going to make a main function with the tweakable parameters. For this specific application, I need a couple extra parameters: the chromosome length for each organism and the target number.

const runAlgorithm = (
  populationSize: number,
  crossoverRate: number,
  mutationRate: number,
  generationLimit: number,
  chromosomeLength: number,
  target: number
): void => {

  ...

From here on, writing the code is not linear. I’m going to fill in the steps of the algorithm as needed.

Implementing Step 3. Create initial population

Since fitness evaluation is to be done in batch, I’m going to make a population of chromosomes instead of organisms.

// Inside runAlgorithm()
const initialChromPopulation: Chromosome[] = buildArray(populationSize)
  .map(_ => randomChromosome(chromosomeLength));

And the helpers to create random chromosomes can go outside the main function…

// Create a randomized chromosome of a desired length.
const randomChromosome = (length: number): Chromosome => {
  const numberGenes: Gene[] = buildArray(Math.floor(length / 2))
    .map(_ => randomGene("number"));
  const operatorGenes: Gene[] = buildArray(Math.floor(length / 2 - 1))
    .map(_ => randomGene("operator"));
  return zip(numberGenes, operatorGenes)
    .flat()
    .concat([last(numberGenes)]);
};

type NumberOrOperator = "number" | "operator";

// Create a randomized number or operator gene.
const randomGene = (numberOrOperator: NumberOrOperator): Gene => {
  switch (numberOrOperator) {
    case "number":
      return [randomBit(), randomBit(), randomBit(), randomBit()];
    case "operator":
      return [randomBit(), randomBit()];
  }
};

// Generate a random bit (0 or 1).
const randomBit = (): Bit => (Math.random() < 0.5) ? 0 : 1;

The main loop

Now I’m going to set up the main loop as a recursive function. This will consist of Steps 4 through 8; fitness evaluation, selection, crossover, mutation, and replacing the population. Each iteration will produce a new generation.

// Inside runAlgorithm()
const generationalStep = (chromPopulation: Chromosome[], generation: number): Chromosome[] => {

  // Check for the stopping condition.
  if (generation >= generationLimit) {
    return chromPopulation;
  }

  ...

Implementing Step 4. Fitness evaluation

Since I’ve already made the fitness evaluation function, here I simply need to apply it to the entire population of chromosomes, turning it into a population of organisms.

// Inside generationalStep()
const population: Organism[] = chromPopulation.map(chromosome => ({
  chromosome,
  fitness: evaluateFitness(chromosome, target)
}));

Implementing Step 5. Selection

This is the first step in the reproduction process. I need to select two organisms from the population using the roulette wheel strategy.

// Inside generationalStep()
const reproduce = (): [Chromosome, Chromosome] => {
  const parent1 = rouletteWheelSelection(population);
  const parent2 = rouletteWheelSelection(population);

  ...

And the roulette wheel selection function can live outside the main function.

// Select an organism from a population using the roulette wheel strategy.
const rouletteWheelSelection = (population: Organism[]): Organism => {
  const fitnesses: number[] = population.map(({fitness}) => fitness);
  const totalFitness: number = sum(fitnesses);
  const cumulFitnesses: number[] = scan((x: number, y: number) => x + y, fitnesses[0], fitnesses);
  const withCumulativeFitnesses: [Organism, number][] = zip(population, cumulFitnesses);
  const r: number = Math.random() * totalFitness;
  const found: [Organism, number] | undefined = withCumulativeFitnesses.find(([_, cf]) => cf >= r);
  if (found === undefined) {
    // In case an organism is not found, return the last one.
    return population[population.length - 1];
  } else {
    const [organism, _] = found;
    return organism;
  }
};

Implementing Step 6. Crossover

The next step for reproduction is crossing over the two previously selected organisms. At this point, I’m going to deal with chromosomes instead of organisms, since their fitnesses won’t be evaluated until later.

// Inside reproduce()
const [chrom1, chrom2] = crossover(parent1.chromosome, parent2.chromosome, crossoverRate);

Again, I can write the crossover function outside the main function.

// Crossover (or clone) two chromosomes.
const crossover = (x: Chromosome, y: Chromosome, crossoverRate: number): [Chromosome, Chromosome] => {
  const r: number = Math.random();
  if (r <= crossoverRate) {
    const position: number = Math.floor(Math.random() * x.length);
    const xNew = [...x.slice(0, position), ...y.slice(position)];
    const yNew = [...y.slice(0, position), ...x.slice(position)];
    return [xNew, yNew];
  } else {
    return [x, y];
  }
};

Implementing Step 7. Mutation

And now for the last step for reproduction: mutating those two chromosomes. After being mutated, the chromosomes can be returned as the pair of produced offspring to end the function.

// Inside reproduce()
const chrom1Mutated = mutate(chrom1, mutationRate);
const chrom2Mutated = mutate(chrom2, mutationRate);

return [chrom1Mutated, chrom2Mutated];
// This ends reproduce()

Once more, the code for mutating can be outside the main function.

// Flip a bit from 0 to 1, or 1 to 0.
const flipBit = (bit: Bit): Bit => bit === 0 ? 1 : 0;

// Mutate a chromosome.
const mutate = (chromosome: Chromosome, mutationRate: number): Chromosome => {
  // Mutate a bit.
  const mutateBit = (bit: Bit): Bit => {
    const r: number = Math.random();
    return r <= mutationRate
      ? flipBit(bit)
      : bit;
  };

  // Mutate each gene.
  return chromosome.map(gene => {
    if (isNumber(gene)) {
      const [a, b, c, d] = gene;
      return [mutateBit(a), mutateBit(b), mutateBit(c), mutateBit(d)];
    }

    if (isOperator(gene)) {
      const [a, b] = gene;
      return [mutateBit(a), mutateBit(b)];
    }

    return gene;
  });
};

Implementing Step 8. Replace population

That finishes the reproduce() function, but I’m not done with generationalStep() yet! I need to make use of the reproduction to make a new population of chromosomes, which will replace the old one.

// Inside generationalStep()
const newChromPopulation: Chromosome[] = buildArray(Math.floor(populationSize / 2))
  .map(reproduce)
  .flat();

Implementing Step 9. Repeat until the stopping condition is met

To repeat the generation cycle, I can simply call generationalStep() recursively, passing in the new population and increasing the generation counter.

// Inside generationalStep()
return generationalStep(newChromPopulation, generation + 1)
// This ends generationalStep()

Implementing Step 10. Pick the winner

Time for the last step! This is where I need to trigger the generational cycle to start, with the initial population of chromosomes, and let it run until the final population.

// Inside runAlgorithm()
const finalChromPopulation: Chromosome[] = generationalStep(initialChromPopulation, 0);

Then evaluate the fitness of each chromosome so I have a population of organisms.

// Inside runAlgorithm()
const finalPopulation: Organism[] = finalChromPopulation.map(chromosome => ({
  chromosome,
  fitness: evaluateFitness(chromosome, target)
}));

And finally, pick the chromosome with the best fitness!

// Inside runAlgorithm()
const winner = finalPopulation.reduce((best, organism) =>
  (organism.fitness > best.fitness) ? organism : best);

I want to print the winner’s information in detail so I can see if the algorithm is producing good results.

// Inside runAlgorithm()
console.log();
console.log(`The winner is...`);
console.log(`Phenotype: ${phenotype(winner)}`);
console.log(`Clean phenotype: ${cleanPhenotype(winner)}`);
console.log(`Result: ${evaluateMath(cleanPhenotype(winner))}`);
console.log(`Fitness: ${evaluateFitness(winner.chromosome, target)}`);
// This ends runAlgorithm()

Running the algorithm

After playing with the parameters, I found that these values gave pretty consistently interesting results, and relatively fast.

const populationSize = 200;
const crossoverRate = 0.6;
const mutationRate = 0.05;
const generationLimit = 20;
const chromosomeLength = 20;
const target = 42;
runAlgorithm(
  populationSize,
  crossoverRate,
  mutationRate,
  generationLimit,
  chromosomeLength,
  target);

Try it out yourself! What happens when you change the values of the parameters? Can you make it accurate and fast?

https://github.com/SlimTim10/genetic-algorithm-math-string

I’m extremely grateful to Danny Fekete and his wife, Carolyn Piccinin, for their indispensable help with editing and vetting the bulk of this work for accuracy. And my partner, Leticia Duque, for her patience in reviewing and her valuable insights.

Overview

Years ago, I stumbled upon a tutorial on genetic algorithms that ended up being one of the most interesting coding exercises I’ve ever done. I still think about it often to this day and I want to bring that same joy to others by providing my own explanation of the subject. This tutorial is meant to be approachable by anyone who knows at least one programming language, beginners and experts alike. Doing this exercise is a great a way to practice a new programming language you’re learning, improve with one you’re already familiar with, or rekindle your passion for programming. Even better, it will also give you a deeper understanding of how evolution works in the real world after simulating it in code.

I’m going to start by explaining the general steps of a standard genetic algorithm. Afterwards, and this is the fun part, I’m going to outline a problem to solve so you can start coding right away! Your resulting program only needs to take a single number as input and print a string as output, so it can have a simple command-line user interface or you can make a fancy web UI—it’s up to you how far you want to take it.

Throughout this tutorial, I’ll be using terms from the topics of natural selection and genetics. You do not need to understand the terms in depth in order to follow along. If you want to learn more about how these things work in the real world, check out this article by Danny Fekete.

A Standard Genetic Algorithm

Very broadly, genetic algorithms attempt to mimic principles of natural selection and genetics to find optimal solutions to problems. The overall idea is, given a target problem, we’re going to encode potential solutions to the problem. Thinking of these potential solutions as organisms, we’ll simulate natural selection, allowing them to evolve into better solutions, and then hopefully leaving us with the kind of great solution we were looking for.

The kinds of problems genetic algorithms are well-suited for are problems in which we know what a good solution would look like, but can’t easily come up with one ourselves. Some use-cases are: the travelling salesman problem, employee shift scheduling (e.g., the nurse scheduling problem), and many more.

In this tutorial, I’m going to describe a standard genetic algorithm, which is easy to code and also recommended by experts. The idea is, once you understand how to code this version of a genetic algorithm, when you have a new problem to solve, you can attempt to apply this algorithm as-is or make modifications to the steps as needed.

Start by using an “off the shelf” GA (genetic algorithm). It is pointless developing a complex GA, if your problem can be solved using a simple and standard implementation.

– Sastry, K., Goldberg, D., Kendall, G. (2005). Genetic Algorithms.

Before we dive into details, here’s a high-level overview of the steps of the algorithm:

• Planning: Before writing any code, we need to answer the question: How do we encode a potential solution to the target problem?
• Setting parameters: There are a few key parameters that need to be set, which will heavily influence the performance of the algorithm each time we run it.
• Create initial population: The first population of organisms is created.
• Fitness evaluation: The fitness of each organism in the entire population is evaluated.
• Selection: Two organisms are selected as parents to reproduce.
• Crossover: The parents produce two offspring by potentially undergoing crossover.
• Mutation: Some genes in the offspring might get mutated.
• Replace population: When there’s enough offspring to form a new population, the old population gets replaced.
• Pick the winner: The fittest organism in the remaining population is your solution!

Step 1. Planning

The first step towards building your own genetic algorithm for a target problem is to plan how potential solutions to the problem will be encoded as organisms. More specifically, how to represent genes and chromosomes, and how to evaluate the fitness of an organism.

Breaking it down from the top, each organism will only be made up of a single chromosome, so the two terms are often interchangeable. (This also means an organism’s entire genome and DNA will be encoded in its one-and-only chromosome, which makes things much simpler than with most real organisms.) All of the information for a potential solution must be encoded in this chromosome.

As in nature, a chromosome is made up of genes, which are like numbered containers for information. In this algorithm, and unlike in nature, chromosomes should all be the same length (i.e., they should contain the same number of genes). This is necessary in order for the crossover step to work as it is described in Step 6.

Each gene’s information only has so many possible variations. A particular variant of a gene is called an allele. Breaking down this last piece, an allele is made up of nucleotides (the building blocks of DNA), which are essentially units of information. In our code, each nucleotide will be represented by one bit (0 or 1), since this is the smallest piece of information on a computer.

Genes, each having their own position in a chromosome, can be different sizes. To determine the size of a particular gene, we need to decide on the number of possible alleles needed for the target problem at that gene. For example, if you choose a gene to be 3 bits in size, that gives

different possible variants of the gene. (The size of a bit is always 2, since there are only two possible values: 0 or 1.)

Each organism should represent a potential solution to the operating problem. An organism’s representation is called its phenotype. For instance, if the expected solution to an operating problem is an English word, each gene in that organism could be expressed as a letter (e.g., “d”). The combined result of its genes would be its phenotype: a string of letters (e.g., “dwnlode”). In this example, we only need one kind of gene because each part of a chromosome is a letter all the same.¹

To allow for 26 (lowercase) letters, we would need genes to be at least 5 bits in length (2⁵ would give us the necessary headroom of 32 possible alleles):

Here’s a breakdown of an example chromosome that could be used for that kind of word-based operating problem:

The first gene in the above chromosome has the allele that represents the value “a”.

Now for fitness. For whatever problem we want our algorithm to solve, we need to know what a good solution looks like because we need some way of knowing which organisms are better than others. The idea here is to come up with a way to evaluate each organism and give it a fitness score (a decimal number). The higher the fitness score, the closer the organism is to an ideal solution. It’s difficult to be more descriptive than this because fitness evaluation varies a lot depending on the problem, so I’ll explain by example.

Let’s say the target problem is to find the best values for a, b, c, and d in the equation a + 2b + 3c + 4d = 30.² Each organism’s phenotype is its particular values for a, b, c, and d. The fitness evaluation for this problem could be:

1 / (abs((a + 2b + 3c + 4d) - 30) + 1)

Where abs gives the absolute value of a number. This evaluation is designed to give a higher fitness score for better values, with 1 being a perfect score. The range is (0, 1], meaning from 0 (exclusive) to 1 (inclusive).

So, an organism with the values a = 0, b = 0, c = 10, and d = 0 would have a fitness of 1…

1 / (((a + 2b + 3c + 4d) - 30) + 1)
= 1 / (((0 + 2(0) + 3(10) + 4(0)) - 30) + 1)
= 1 / (0 + 1)
= 1

…which is a perfect score! This makes sense, because these values perfectly satisfy the target equation.

a + 2b + 3c + 4d = 30
0 + 2(0) + 3(10) + 4(0) = 30
30 = 30

Step 2. Setting parameters

The algorithm has four major parameters that must be set. These will affect how well the algorithm performs each time it runs on a target problem. Once you’ve finished implementing your algorithm, these are the parameters you’ll want to play with and see how it performs differently.

Population size

This is the number of organisms in the population for each generation. We’ll call this parameter populationSize.

A good starting point is populationSize = 50.

Crossover rate

As pairs of organisms are selected to reproduce for the next generation, they may produce exact copies or be combined (like sexual reproduction in the real world). The crossover rate is the probability that each pair of selected organisms will be crossed over, which will be explained in Step 6. We’ll call this parameter crossoverRate.

A good starting point is crossoverRate = 0.6.

Mutation rate

Every bit of information in every chromosome has a (low) chance to be mutated, which will be explained in Step 7. Mutations can spark new traits that can then be carried to future generations, adding diversity to the population. We’ll call this parameter mutationRate.

A good starting point is mutationRate = 0.05.

Stopping condition

At some point, the algorithm has to stop, otherwise you’ve created an infinite loop! The easiest stopping condition to implement is to set a limit on the number of generations. When the limit is reached, take the organism with the highest fitness from the last generation’s population and you have a solution!

Alternately, you could let the stopping condition be a fitness threshold. When a organism’s fitness meets the threshold, halt and deem it the winner!

Step 3. Create initial population

The first generation of organisms needs to come from somewhere. A good way to make the first population is to randomly generate every bit of information in every organism’s chromosome until the number of organisms is equal to populationSize. That way, all the organisms in the population will have completely random genes.

Step 4. Fitness evaluation

Let the games begin! Evaluate the fitness of every organism in the population and store this information to be used in the next step.³

Step 5. Selection

This step begins the reproduction process (along with the next two steps). The current population needs to be used to form a new population (the next generation). Essentially, we’re going to select pairs of organisms from the current population and have them reproduce to form offspring. Each pair will produce two offspring, and once we have enough offspring (determined by populationSize), they will replace the current population.

Since the goal of the algorithm is to work towards a better solution, this step is where we simulate competition. In nature, not all members will reproduce equally—some will thrive and have lots of offspring while others will be less successful by comparison (due to death, inability to find a mate, etc.). Instead of just selecting organisms at random, the probability that an organism is selected should be proportional to its fitness. After all, this is the purpose of an organism’s fitness! It should be more likely for high-performing organisms to be selected for reproduction than their lower-performing peers. For this, we’re going to use the roulette wheel strategy.

Let’s say we have a population of five organisms:

(Don’t pay much attention to the chromosome values in this example. I made them up randomly.)

At a casino, every segment of a roulette wheel is equal in size. But our goal is to make a rigged roulette wheel where the segments are proportional to their fitness:

Now, when we spin the wheel to select an organism, it’s obvious there will be a bigger chance to land on organism 4 than any other organism.

If you want more direct instructions on implementing the roulette wheel strategy in code, click/tap below. Or, you can enjoy devising the algorithm on your own!

We have now met the overall goal of this step: to select two organisms while accounting for their fitness, which will be used in the next step to produce a pair of offspring.⁴

Step 6. Crossover

The purpose of this step is to involve an important aspect of natural selection: heredity. Offspring tend to resemble some combination of their parents (and diminishingly, their more distant ancestors). We’re going to achieve this through reproduction by breeding or cloning. The offspring of the two previously selected organisms will either inherit a combination of their traits (genes from both parents) or be clones of the parents.

To check if a crossover should happen, generate a random number, r, between 0 and 1. If r is less than or equal to crossoverRate, perform a crossover. Otherwise, let the offspring be exact copies of the parents (put simply, the parents become the offspring).

To crossover two organisms, pick a random position between the genes of a chromosome and swap all the alleles to the right in the first chromosome with the corresponding alleles in the second chromosome. (Remember, our chromosomes are supposed to contain the same number of genes, so this makes it easy to line them up and cut them at the same spot.)

Step 7. Mutation

Due to mutation in nature, novel or modified characteristics occasionally show up that do not appear to have belonged to an ancestor, but can still be passed on to offspring like any other trait. Combined with heredity, this suggests that a population has a capacity for change beyond just an endless recombination of preexisting traits. And due to fitness-based selection, occasionally a novel trait will arise that confers a competitive advantage (e.g., the organism that has that new trait is better able to survive and reproduce because of it). These traits will then enter and proliferate across the population through subsequent generations.

To simulate genetic mutation in code, we allow the newly formed offspring the potential to mutate. For each bit in each offspring’s chromosome:

• Generate a random number, r, between 0 and 1.
• If r is less than or equal to mutationRate, mutate the bit. To mutate, simply flip the bit (0 to 1, or 1 to 0).

Step 8. Replace population

Steps 5 to 7 (selection, crossover, and mutation) taken as a cycle together form the reproduction process. Each cycle produces two offspring. We need to repeat the cycle until we get enough offspring to form a new population (populationSize), which immediately replaces the old population. The old population won’t be needed anymore (everything dies…). (For practical purposes, this means offspring never reproduce with the previous generation.)

Step 9. Repeat until the stopping condition is met

As the gods of this artificial world of digital organisms, we decide when the simulation ends.

Steps 4 to 8 form the main loop of the algorithm. Each iteration of that loop is one generation. The planned stopping condition marks the end of the loop, which leaves us with the last generation’s population. If the stopping condition is a limit on the number of generations, say 100, then we simply stop after repeating 100 iterations.

Step 10. Pick the winner

In the remaining population, pick the organism with the highest fitness. There’s your solution!

A Target Problem

Just reading about genetic algorithms won’t be enough to grasp this concept; you need to try implementing a genetic algorithm on your own. But first, you need the right kind of problem to solve. Lucky for you, I’ve got that part covered! In this section, I’m going to outline a problem and give you all the necessary details so you can start coding in any programming language you want. In other words, I’m going to cover Step 1 (planning) and you have to do the rest.

The Problem

Given a target number, find a human-readable string of single-digit numbers and basic arithmetic operators that equals that number. For example, if the target number is 10, some solutions would be:

• 5 + 5
• 5 * 2
• 5 + 5 + 1 - 1 - 5 - 5 + 1 + 9 * 1 / 1

Note: Because the solutions should take the form of math strings, you should decide how those strings get evaluated. For example, they could be evaluated left-to-right or use the standard order of operations (multiplication > division > addition > subtraction). So, 2 + 2 * 3 = 8 or 2 + 2 * 3 = 12. Feel free to choose whichever evaluation method is easier for you to implement.

Implementing Step 1. Planning

Since all of the example solutions (above) equal 10 exactly, in a genetic algorithm they would all be ideal matches with perfect fitness. Of course, there are many possible solutions to reach any target number and our genetic algorithm may not discover any of them in the limited time it has to run. So, the true goal of our genetic algorithm is to give us the best candidate after a certain number of generations. After all, genetic algorithms aren’t guaranteed to give perfect solutions every time.

In this problem, a potential solution is to be a string of single-digit numbers and arithmetic operators, so that is exactly what an organism’s chromosome should represent. The genes, being pieces of a chromosome, should therefore each express a single-digit number or an arithmetic operator. More specifically, we want strings that alternate between numbers and operators (number operator number operator …). So, let’s have two kinds of genes: a number gene and an operator gene.

To determine gene size, we need to know how many possible alleles are necessary. For number genes, the required values are single-digit numbers: 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9. That’s ten possible alleles in total, so we need a minimum of four bits per gene (giving us 2⁴ = 16 different possible alleles). We’ll have a few alleles left over, but we can consider them junk if they turn up in the resulting chromosome. So, our alleles for number genes are:

For operator genes, we need to represent four basic math operators: +, -, *, and /. Conveniently, we can use two bits for exactly four different possible values:

As an example, we could have the following organism’s chromosome and its phenotype:

When evaluating a math string (an organism’s phenotype), we’ll have to clean up any junk it may have. Let’s say, for any junk in the string, ignore the junk gene and its immediately preceeding gene (which should be an operator).

Here’s an example with clean-up:

[0101 10 0010 00 1010 01 0001 00 1000 11 1111 00 0010]
= 5 * 2 + (junk) - 1 + 8 / (junk) + 2
= 5 * 2 - 1 + 8 + 2
= 19

Now we need to decide how the fitness of an organism should be evaluated. Recall that we need an evaluation function which produces a higher number for organisms that are closer to the ideal solution. Ideally, we should fit the fitness number into the range (0, 1], since this makes the roulette wheel selection easier. Try to come up with this function yourself, or click/tap to see my suggestion below (there’s more than one right answer!).

Watch out! It is very possible for division by 0 to be part of a phenotype. I’ll leave it up to you to decide how to handle it, but do expect it to happen and think about your options.

Build it!

That’s it! Now you’re on your own to code this algorithm by implementing Steps 2 through 10. In the end, you should have a program which, given a target number, produces a math expression for that number. Remember, if you’re not getting good results, try tweaking the parameters.

Food for Thought

Why a chance of crossover?

Why is it important to have a chance of crossover not happening? Suppose we have two organisms, Alice and Bob, selected to be parents. Alice’s fitness is 99% and Bob’s is 80%. If Alice and Bob are to produce offspring who inherit from both of them, the offspring are almost guaranteed to have a lower fitness than Alice’s 99%. A preferable outcome would be for Alice’s offspring to exclusively contain her genes—without any crossover with Bob—resulting in a clone. (That final percentage point of fitness might be then achieved with a lucky mutation.)

Can organisms breed with themselves?

Did you notice, in the reproduction process, it’s possible for an organism to be paired with itself? The exact same organism can be selected twice in a row! Then, in the crossover step, whether a crossover happens or not, we’ll get two identical offspring. So really, one organism can be taken from the current population to produce two of itself for the next population. What are the possible implications of this when the algorithm runs?

What does cloning represent?

When a crossover doesn’t occur, the offspring are clones of the parents. What does it mean to produce clones? Are we simulating an organism that reproduces both sexually and asexually? Or are we representing organisms that simply carry on living into the next generation?

What are the traits?

In the real world, organisms can be described as having many traits. In the target problem described above, what are the traits of an organism? Do each of our organisms only have a single trait: its evaluated number? Or can we think of each expressed allele as a trait?

When does crossover help?

In the target problem described above, does crossing over two high-fitness organisms have a good chance of producing high-fitness offspring? Swapping genes seems likely to drastically, and almost randomly, change a organism’s phenotype. It seems more like mutating a chunk of a chromosome than inheriting traits.

What are other ways of representing organisms in the target problem?

The plan I laid out for the target problem is only one of many options. What are some other ways you could define genes and chromosomes to build math strings? Do we need more than one kind of gene?

Footnotes

This post is about the concept of currying, from functional programming, and when you should use it in JavaScript.

I’m going to be honest. You probably don’t need to use currying in JavaScript. In fact, trying to fit it in your code is going to do more harm than good, unless it’s just for fun. Currying only becomes useful when you fully embrace functional programming, which, in JavaScript, means using a library like Ramda instead of the standard built-in functions.

In this article, I’m going to start by explaining what currying is, then show how it can be useful in a functional programming context.

What is currying?

Currying is the concept that functions never need to take multiple arguments; every function only takes a single argument. If a function needs to behave as if it takes multiple arguments, it returns another function instead.

A regular, non-curried function is what you’re used to seeing:

const add = (x, y) => x + y

console.log(
  add(2, 3) // 2 + 3
) // prints 5

This is a simple function that takes two numbers and returns their sum.

A curried version of the same function looks like this:

const addCurried = x => y => x + y

console.log(
  addCurried(2)(3) // 2 + 3
) // prints 5

Instead of the function taking two arguments, it takes one argument, then returns another function that takes one argument and returns the sum. Notice how we have to pass the arguments to the function using more brackets, since the arguments are passed one at a time to each nested function.

We can have as many arguments as we want this way:

const addMore = a => b => c => d => e => a + b + c + d + e

console.log(
  addMore(1)(2)(3)(4)(5) // 1 + 2 + 3 + 4 + 5
) // prints 15

Because of the way a curried function works, we can do something called partial application. This is when we give a function fewer arguments than it can take:

const addCurried = x => y => x + y

console.log(
  addCurried(2) // y => 2 + y
) // [Function (anonymous)]

If we only pass addCurried one argument, the result is a function that expects another argument. In other words, the 2 went into the x argument, so we’re left with y => 2 + y. If we want, we can store this partially applied function into a variable so we can use it after the fact:

const addCurried = x => y => x + y
const add2 = addCurried(2)
// This is the same as:
// const add2 = y => 2 + y

console.log(
  add2(3) // 2 + 3
) // prints 5

console.log(
  add2(10) // 2 + 10
) // prints 12

Now we have a function add2, which is expecting a single argument. Whatever we give it, it will add 2 to it.

When is currying useful?

Like I said, in a typical JavaScript codebase, it’s not. You can probably tell that the addCurried example is very contrived and doesn’t demonstrate any real benefit. But if you want to go deeper down the functional programming rabbit hole, let me show you how using curried functions can be even more elegant than the typical practice.

It’s all about composition.

In functional programming, composing functions is a fundamental concept. This means using one function after another on some data. It’s in using composition that curried functions really shine.

In JavaScript, the way to compose two functions looks like this:

const compose = (f, g) => x => f(g(x))

const addCurried = x => y => x + y

console.log(
  compose(addCurried(2), addCurried(3))(10) // 10 + 3 + 2 = 15
) // prints 15

When using composition, you should read it as operations being done on some data from right to left. In the above example, the starting data is 10, which goes through adding 3, followed by adding 2, resulting in 15.

Let me show by example how composing a series of curried functions looks when compared to idiomatic functional JavaScript. I’m going to use an example based on a real problem I had to solve that doesn’t call for any particular programming style or language.

The objective is to make a function cleanExpression that takes in a basic math expression as a string (e.g., “1 + 10 / 2”) and returns a cleaned version of it. The cleaning process is to remove extra spaces and make sure the expression alternates numbers and operators (there should never be two numbers or two operators next to each other). We’re dealing with single-digit numbers only.

For example, “1    + 2 2 / 3 *” cleaned would be “1 + 2 / 3”.

The following is an idiomatic functional JavaScript solution. Let’s call this “functional-lite”.

// Helper functions
const isOperator = x => "+-*/".includes(x)

const isDigit = x => "1234567890".includes(x)

const last = xs => xs[xs.length - 1]

const init = xs => xs.slice(0, -1)

const intersperse = (sep, xs) => xs.map(x => [sep, x]).flat()

// The main function
const cleanExpression = expr => {
  const parseNext = ([acc, shouldBe], x) => {
    if (shouldBe === 'digit' && isDigit(x)) {
      return [[...acc, x], 'operator']
    } else if (shouldBe === 'operator' && isOperator(x)) {
      return [[...acc, x], 'digit']
    } else {
      return [acc, shouldBe]
    }
  }

  const chars = expr.split('')
  const alternating = chars.reduce(parseNext, ['', 'digit'])[0]
  const cleaned = isOperator(last(alternating)) ? init(alternating) : alternating
  return intersperse(' ', cleaned).join('')
}

console.log(
  cleanExpression('1    + 2 2 / 3 *')
)

And here is a more functional JavaScript solution using the Ramda library in-place of built-in functions:

const R = require('ramda')

const isOperator = x => R.includes(x, "+-*/")

const isDigit = x => R.includes(x, "1234567890")

const cleanExpression = expr => {
  const parseNext = ([acc, shouldBe], x) => {
    if (shouldBe === 'digit' && isDigit(x)) {
      return [acc + x, 'operator']
    } else if (shouldBe === 'operator' && isOperator(x)) {
      return [acc + x, 'digit']
    } else {
      return [acc, shouldBe]
    }
  }

  return R.compose(
    R.join(''),
    R.intersperse(' '),
    (xs => isOperator(R.last(xs)) ? R.init(xs) : xs),
    R.head,
    R.reduce(parseNext, ['', 'digit']),
    R.split('')
  )(expr)
}

console.log(
  cleanExpression('1    + 2 2 / 3 *')
)

Fewer helper functions are needed because Ramda implements the others, but that’s not what’s important. The main lines to compare are in the body of cleanExpression:

// functional-lite
const chars = expr.split('')
const alternating = chars.reduce(parseNext, ['', 'digit'])[0]
const cleaned = isOperator(last(alternating)) ? init(alternating) : alternating
return intersperse(' ', cleaned).join('')

// more functional
return R.compose(
  R.join(''),
  R.intersperse(' '),
  (xs => isOperator(R.last(xs)) ? R.init(xs) : xs),
  R.head,
  R.reduce(parseNext, ['', 'digit']),
  R.split('')
)(expr)

Ramda’s compose function extends function composition to any number of functions instead of only two. Still, it should be read from right to left (or bottom to top). The above example can be understood as:

• Feed in expr as the data to be operated on, which in this case should be a math expression as a string.
• Split the string, turning it into an array of characters.
• Use reduce to walk through the expression, building a new version that alternates digits and operators (beginning with a digit).
• Take the first element of the previous result (because it returned a pair and we only need the new expression).
• Remove the last character if it is an operator.
• Intersperse the new expression with spaces.
• Finally, Convert the new expression into a string.

This way, we can think of the solution as processing some data through a pipeline (bottom to top). The output of each step feeds into the input of the next one until we reach the end, which gets returned as a final result.

The steps of the solution are the same in both versions, but the second version looks more linear and we can clearly see each step.

For the most functional version, here’s the same solution in Haskell, where all functions are curried by default and the composition operator is a dot (.) :

isOperator :: Char -> Bool
isOperator x = x `elem` "+-*/"

isDigit :: Char -> Bool
isDigit x = x `elem` "1234567890"

intersperse :: Char -> String -> String
intersperse sep = init . concat . map (\x -> [x, sep])

cleanExpression :: String -> String
cleanExpression =
  intersperse ' '
  . (\xs -> if isOperator (last xs) then init xs else xs)
  . fst
  . foldl parseNext ("", "digit")
  where
    parseNext :: (String, String) -> Char -> (String, String)
    parseNext (acc, shouldBe) x
      | shouldBe == "digit" && isDigit x =
        (acc ++ [x], "operator")
      | shouldBe == "operator" && isOperator x =
        (acc ++ [x], "digit")
      | otherwise = (acc, shouldBe)

main :: IO ()
main = do
  print $ cleanExpression "1    + 2 2 / 3 *" == "1 + 2 / 3"

Conclusion

Currying is not a very complicated concept, but most people are unfamiliar with it because they have no use for it. And for good reason! It only shines when you decide to write very functional code and use composition everywhere. Languages like Haskell take advantage of this by defining all functions to be curried by default and having a very small operator for composing functions (like a dot).

For a fun exercise, try implementing Ramda’s compose function on your own! It should be able to compose any number of functions, not just two.

(This is a continuation from Part I, a philosophical exploration about programming, with sandwiches. Go read it first, if you haven’t yet.)

In Part I, I talked about error handling, mutability and state, and programming paradigms. Now it’s time to look at a problem from the perspective of using type theory. My original plan was, after writing an idiomatic Haskell solution to making abstract sandwiches, to write a Haskell solution using type-level programming techniques. Writing an Agda solution was going to be the last step. Well, plans change. After some attempts at trying to write a meaningful type-level Haskell solution, I realized that Haskell’s type system is simply not equipped to express these kinds of ideas nearly as well as Agda’s.¹ Let me explain.

Defining a Sandwich as a Type

At the end of Part I, I explained how it’s easily possible to make an impossible sandwich with the previously proposed solution. Let’s see how we can fix that.

In the context of this exploration, I’m going to define a sandwich as follows:

A sandwich consists of a bottom and a top, which are both slices of bread. Neither the bottom or top can be smeared on the outside. At least one of the bottom or top must be smeared on the inside. A sandwich may be in one or more pieces (i.e., it can be cut).

I know, this doesn’t cover nearly all the exotic sandwiches you have in mind. I want to keep the scope of this problem small so the code is easier to understand, so we’re just going to deal with peanut butter and/or jelly sandwiches. To be clear, the reason sandwiches can’t be smeared on the outside is it makes them icky to hold.

So, with that definition in mind, let’s look at the Haskell sandwich from Part I and see where it falls short.

data Sandwich = Sandwich
  { bottom :: SliceOfBread
  , top :: SliceOfBread
  , pieces :: Integer
  }

(This isn’t exactly what I had in Part I. Here, I’ve made a small change to simplify the problem: instead of keeping track of the pieces and their details, we’re only interested in the number of pieces.)

What we have here is a definition of a Sandwich type in Haskell. The concept of type theory is that there are types and values (also called terms or elements). A value belongs to a certain type. No value exists without a type. When we think or program in type theory, we define what something is by making a new type for it. Then, we can make values of that type. Just like I gave an English definition of a sandwich (type), I can now go make an actual sandwich (value) and say that it fits the definition. For object-oriented programmers, it can help to think of types as being like classes and values as being like instances of a class.

Taking our Sandwich type and reverse engineering it into English, we get:

A sandwich consists of a bottom and a top, both slices of bread. (Off to a great start!) A sandwich may be in any number of pieces.

Hmm. This doesn’t quite match our desired definition. First, there’s nothing about smearing. And, the sandwich can be in zero or even negative pieces! Now, to be fair, the smearing is included in the SliceOfBread type:

data SliceOfBread = SliceOfBread
  { flavour :: BreadFlavour
  , top :: Maybe Condiment
  , bottom :: Maybe Condiment
  }

This type says, “a slice of bread is of a certain flavour and may be smeared with a condiment on the top and/or bottom.”

So, there is something about smearing, but it doesn’t have the restriction we want, about the sandwich’s bottom and top being smeared only on the inside. In fact, with Haskell’s type system, we can’t represent that! Our only option is to leave the type as it is and handle the proper making of a sandwich in the logic of functions and thread error handling through all those functions (using Either). But, as we’ve seen (in Part I), that still leaves us with the ability to make improper sandwiches if we forego the use of those functions. For example:

-- Two plain slices of bread shouldn't be considered a sandwich.
-- Not to mention it's in 0 pieces. What is this? An eaten sandwich?
badSandwich = Sandwich
  { bottom = SliceOfBread { flavour=Sourdough, top=Nothing, bottom=Nothing }
  , top = SliceOfBread { flavour=Sourdough, top=Nothing, bottom=Nothing }
  , pieces = 0
  }

The purpose of embedding our ideal definitions in types is to make it impossible to do things wrong. I don’t want it to be possible to make an improper sandwich, or even fail at any step along the way. That brings us to Agda.

Agda is a dependently typed programming language. Dependent types allow us to represent things intuitively. A dependent type is a type whose definition depends on a value. In the Sandwich type, its bottom has the type SliceOfBread, but that’s not enough information. We want it to be a SliceOfBread that is not smeared on its bottom. In other words, its type should be a SliceOfBread whose value looks something like this:

SliceOfBread { flavour=?, top=?, bottom=Nothing }

All this to say, the type of a sandwich’s bottom slice depends on its value.

In Agda, we can represent a sandwich like this:

record Sandwich : Type where
  field
    top : SliceOfBread
    bottom : SliceOfBread
    shellOk : checkShell top bottom
    pieces : Σ n ꞉ ℕ , n ≥ 1

In English, this means:

A sandwich must have all of the following properties:

• a top, which is a slice of bread
• a bottom, which is a slice of bread
• a proof that the shell is OK
• be cut into 1 or more pieces

Where’s the part about smearing? Well, that’s covered by the “proof that the shell is OK”. I’m calling the top and bottom slices of the sandwich its “shell”. The checkShell function looks like this:

checkShell : SliceOfBread → SliceOfBread → Type
checkShell top bottom =
  -- The top slice is not smeared on its top
  is-nothing (smearedTop top)
  -- and the bottom slice is not smeared on its bottom
  × is-nothing (smearedBottom bottom)
  -- and either the bottom is smeared on its top or the top is smeared on its bottom (or both).
  × (is-just (smearedBottom top) ∔ is-just (smearedTop bottom))

The type signature of this checkShell function says it takes in two slices of bread (a top and a bottom) and returns a type. Not a value of a specific type, like a boolean, but rather a value that is a type itself. A function returning a type as a value might seem like an odd thing, and it should, because it only makes sense in Agda-land. What does it mean? Why not return a boolean (true or false)? Well, if we return a boolean, we will have to check if the function returns true wherever we use it. But remember, we’re trying to make it impossible to build an improper sandwich. So, instead of checking that the function returned the right value, we can have a function that can only return a value if its arguments pass its validation check. This idea from type theory, often called “propositions as types”, is the idea that an element of a type is a proof of a theorem. In checkShell, the only elements of its resulting type are proofs that the top and bottom slices are smeared appropriately, as checked by the body of the function. Take a moment to digest this. Now, the Sandwich property shellOk has the type of checkShell top bottom, which means shellOk is a proof that the shell of the sandwich is OK! Anytime we want to make a value of the type Sandwich, we need to provide a proof that its shell is OK.

Altogether, this means we can only create a value of type Sandwich if it is a proper sandwich! And the type of Sandwich (together with checkShell) represents our original definition accurately:

A sandwich consists of a bottom and a top, which are both slices of bread. Neither the bottom or top can be smeared on the outside. At least one of the bottom or top must be smeared on the inside. A sandwich may be in one or more pieces (i.e., it can be cut).

Dependently Typed Utensils

In Part I, I encoded utensils in Haskell like this:

data Condiment = PeanutButter | Jelly

data UtensilShape = Knife | Spoon | Fork

data Utensil = Utensil
  { shape :: UtensilShape
  , loadedWith :: Maybe Condiment
  }

These are type definitions. A utensil has a shape (knife, spoon, or fork) and may be loaded with a condiment. Now, the problem is, I wanted to say that a utensil has a shape and may be loaded with a condiment if its shape is a knife. But we can’t write that in Haskell because loadedWith would depend on the value of shape.

Since Agda is dependently typed, we can easily write this!

-- We only have peanut butter and jelly in the pantry.
data Condiment : Type where
  peanutButter jelly : Condiment

data UtensilShape : Type where
  knife spoon fork : UtensilShape

record Utensil : Type where
  field
    shape : UtensilShape
    loadedWith : Maybe ((shape ≡ knife) × Condiment)

The Maybe type works the same as in Haskell, where the possible values of Maybe a are:

• nothing, or
• just x, where x is a value of type a.

The part (shape ≡ knife) × Condiment describes a pair of values (x , y), where x is a proof that the shape is a knife and y is a condiment.

Now, the only possible values of loadedWith are:

• nothing
• just (refl knife , peanutButter)
• just (refl knife , jelly)

refl knife is a proof that the shape is a knife (when it is, in fact, a knife).

We can make a knife loaded with peanut butter like this:

pbKnife : Utensil
pbKnife = utensil knife (just (refl knife , peanutButter))

If we try to make a fork loaded with peanut butter, we can’t:

pbFork : Utensil
pbFork = utensil fork (just (? , peanutButter))

Nothing fits in the question mark! We would need to provide a proof that fork ≡ knife, which is obviously impossible. We can only make a fork that’s clean:

cleanFork : Utensil
cleanFork = utensil fork nothing

Dependently Typed Actions

Now, for the sake of exploration, I wanted to see how far I could take this. So far, I’ve only shown implementions for static things, like sandwiches and utensils, but there’s more to the problem. In the Haskell code from Part I, there’s a function to fetch a utensil of a specified shape:

fetchUtensil :: UtensilShape -> Utensil
fetchUtensil s = Utensil
  { shape = s
  , loadedWith = Nothing
  }

This function takes a utensil shape and returns a clean utensil of that shape. However, the type signature of the function only says it takes a utensil shape and returns a utensil. It doesn’t specify that the returned utensil will be the right shape or that it will be clean; that’s left to the body of the function. The common approach to making sure this function is implemented correctly is to write tests for it:

testFetchUtensil :: IO ()
testFetchUtensil = do
  print (fetchUtensil Knife == Utensil { shape = Knife, loadedWith = Nothing })
  print (fetchUtensil Fork == Utensil { shape = Fork, loadedWith = Nothing })
  print (fetchUtensil Spoon == Utensil { shape = Spoon, loadedWith = Nothing })

Now, if we accidentally wrote fetchUtensil to always return a knife,

fetchUtensil :: UtensilShape -> Utensil
fetchUtensil s = Utensil
  { shape = Knife
  , loadedWith = Nothing
  }

our tests would catch the mistake.

But there’s another approach we can take. Using dependent types in Agda, we can give the function the type of “taking a utensil shape and returning a clean utensil of that shape”, just like I wanted to describe it.

fetchUtensil
  : (s : UtensilShape)
  → Σ u ꞉ Utensil , (shape u ≡ s) × is-nothing (loadedWith u)
fetchUtensil s = utensil s nothing , refl s , refl

What this type really says is, “take a utensil shape and return a pair of values (u , p) where u is a utensil and p is a proof that u has the given shape and is clean.” Then, the function body has no choice but to implement exactly that type. If we implement it any other way, the code won’t compile! This is the difference: having our mistakes caught during compiling versus running the code. If the function’s meaning is encoded in its type, our code won’t compile unless the function’s body honors that type.

To be clear, I’m not advocating for all programs to be written in Agda. It’s not a programming language meant for producing general purpose applications. In fact, it’s only meant for writing (mathematical) proofs. But! It’s a great tool for discovering, planning, and expressing ideas rigorously. If the kids in the Exact Instructions Challenge video had planned the steps to making a sandwich in Agda, they would have left no room for their dad to make mistakes. Silly dad, dependent types are for kids!

Just for fun, here’s the most complex part of the sandwich solution in Agda versus in Haskell. Not for the faint of heart!

Haskell:

loadFrom :: Utensil -> CondimentJar -> Either String (Utensil, CondimentJar)
loadFrom _ CondimentJar{lid=Closed} = Left "The jar is closed and knife-impermeable."
loadFrom _ CondimentJar{condiment=Nothing} = Left "The jar is empty. How disappointing."
loadFrom Utensil{shape=Fork} _ = Left "Forks aren't the right shape for condiments."
loadFrom u cj@CondimentJar{condiment=Just c}
  = Right (u { loadedWith = Just c }, cj { condiment = Nothing })

Agda:

-- A Maybe value is left unchanged if we map it to the second value of a pair and project that second value.
-- Needed to prove this for part of loadFrom (following).
map-pr₂-pair-refl
  : {A B : Type} {b : B} (ma : Maybe A)
  → ma ≡ map pr₂ (map (λ (a : A) → (b , a)) ma)
map-pr₂-pair-refl {A} {B} {b} (just x) = refl (just x)
map-pr₂-pair-refl {A} {B} {b} nothing = refl nothing

-- Load a clean knife with a condiment from a jar that is open and full.
-- Take a utensil that is a knife and clean.
-- Take a condiment jar that is full and open.
-- Return the knife, now loaded with the condiment from the jar,
--   and the condiment jar, still open but now empty.
loadFrom
  : (uₛ : Σ u ꞉ Utensil , (shape u ≡ knife) × is-nothing (loadedWith u))
    (cjₛ : Σ cj ꞉ CondimentJar , is-just (condiment cj) × (state cj ≡ open'))
  → Σ (u' , cj') ꞉ Utensil × CondimentJar
    , (shape u' ≡ shape (pr₁ uₛ)) -- Same shape (*the* knife)
      × (condiment (pr₁ cjₛ) ≡ map pr₂ (loadedWith u')) -- Loaded with condiment from jar
      × (state cj' ≡ state (pr₁ cjₛ)) -- State unchanged (still open)
      × is-nothing (condiment cj') -- Now empty
loadFrom
  (u , isKnife , notLoaded)
  (cj , isFull , isOpen)
  = (record u { loadedWith = loadedWith' } , record cj { condiment = nothing })
    , refl (shape u) , isLoaded' , refl (state cj) , refl
  where
  loadedWith' : Maybe ((shape u ≡ knife) × Condiment)
  loadedWith' = map (λ x → (isKnife , x)) (condiment cj)

  isLoaded' : condiment cj ≡ map pr₂ loadedWith'
  isLoaded' = map-pr₂-pair-refl (condiment cj)

Making a Sandwich

Now that I’ve shown how static things and actions can be written in Agda, how about using these individual parts together to make a sandwich? Remember, the main goal of this whole exercise is to demonstrate what it would be like to program a computer to make a sandwich (without ending up with a real sandwich being squeezed out the USB port).

I’m going to show a few examples of attempts at making a sandwich and how mistakes are caught. To be clear, a failed attempt doesn’t mean something is wrong with the functions for making sandwiches; it’s the opposite! It’s showing how the code forces us to make proper sandwiches. In each of these attempts, I’m going to mock getting items from the kitchen by invoking fetching functions like fetchUtensil, but it should be understood that any method of creating a value of a certain type equates to fetching it in the real world (things don’t magically come into existence).

Attempt 1: Forgot to open the jar of peanut butter

This attempt didn’t result in a completed sandwich because we forgot to open the jar of peanut butter.

sandwichAttempt1 : Sandwich
sandwichAttempt1 = {!!}
  where
  -- Get a knife with peanut butter.
  step1 : Σ _ ꞉ Utensil × CondimentJar , _
  step1 =
    let
      newKnife : Utensil
      newKnife = pr₁ (fetchUtensil knife)
      pb : CondimentJar
      pb = pr₁ (fetchCondimentJar peanutButter)
    -- Not possible because the pb jar isn't open!
    in loadFrom (newKnife , (refl knife , refl)) (pb , ((peanutButter , refl) , {!!})) -- closed ≡ open'

In Agda, {!!} denotes a hole to be filled with some value of the expected type. When writing Agda code, it’s typical to have lots of holes, and the goal is to fill them all with appropriate types (and with interactive assistance of Agda, which is really cool!). The first hole, in sandwichAttempt1 = {!!} is expecting a value of type Sandwich. Since this is a failed attempt at making a sandwich, this hole will be left unfilled. The real evidence that this attempt isn’t going to work is on the last line:

loadFrom (newKnife , (refl knife , refl)) (pb , ((peanutButter , refl) , {!!}))

The hole at the end of that line is expecting a value of the type closed ≡ open', meaning a proof that closed is the same as open. It’s expecting this type because loadFrom takes an open condiment jar as its second argument and we’ve given it a closed one, pb. Obviously, we can’t supply a proof that the given jar is open because it’s not! So this hole must remain unfilled, and we’ll stay hungry.

Attempt 2: Tried to make a sandwich without condiments

sandwichAttempt2 : Sandwich
sandwichAttempt2 = sandwich topSlice' bottomSlice' (refl , refl , {!!}) (1 , ⋆)
  where
  -- Get a knife with peanut butter.
  step1 : Σ _ ꞉ Utensil × CondimentJar , _
  step1 =
    let
      newKnife : Utensil
      newKnife = pr₁ (fetchUtensil knife)
      pb : CondimentJar
      pb = pr₁ (fetchCondimentJar peanutButter)
    in loadFrom (newKnife , (refl knife , refl)) (pr₁ (openJar pb) , ((peanutButter , refl) , refl open'))

  -- Get a couple slices of bread.
  topSlice' : SliceOfBread
  topSlice' = pr₁ (fetchSliceOfBread wholeGrain)
  bottomSlice' : SliceOfBread
  bottomSlice' = pr₁ (fetchSliceOfBread sourdough)

This time, we got closer to making a proper sandwich! In step1, we got a knife and loaded it with peanut butter from a jar. Then, we got a couple slices of bread. We didn’t bother to use our knife or spread any condiments on either slice; we just left them plain. When we tried to make a sandwich out of these plain slices, we ended up with a hole:

sandwich topSlice' bottomSlice' (refl , refl , {!!}) (1 , ⋆)

This hole is expecting a value of the type is-just (smearedBottom topSlice') ∔ is-just (smearedTop bottomSlice'), which means a proof that the top slice is smeared on its bottom or the bottom slice is smeared on its top. Since our slices are plain, we can’t provide that!

Attempt 3: Successful sandwich making!

Okay, this is a long one. Hey, it takes a lot of work to make a proper sandwich!

sandwichAttempt3 : Sandwich
sandwichAttempt3 = sandwich topSliceWithJelly bottomSliceWithPB (refl , (refl , inl (jelly , refl))) (1 , ⋆)
  where
  -- Get a knife with peanut butter.
  step1 : Σ _ ꞉ Utensil × CondimentJar , _
  step1 =
    let
      newKnife : Utensil
      newKnife = pr₁ (fetchUtensil knife)
      pb : CondimentJar
      pb = pr₁ (fetchCondimentJar peanutButter)
    in loadFrom (newKnife , refl knife , refl) (pr₁ (openJar pb) , (peanutButter , refl) , refl open')

  -- Get a slice of bread and smear it with the PB knife.
  step2 : Σ _ ꞉ SliceOfBread × Utensil , _
  step2 =
    let
      bottomSlice : SliceOfBread
      bottomSlice = pr₁ (fetchSliceOfBread sourdough)
      pbKnife : Utensil
      pbKnife = pr₁ (pr₁ step1)
      emptyPB : CondimentJar
      emptyPB = pr₂ (pr₁ step1)
    in
      smearSliceOfBread
      (pbKnife , (refl (shape pbKnife)) , ((refl (shape pbKnife)) , peanutButter) , refl)
      top
      (bottomSlice , (inl (refl top , refl)))

  -- Our successfuly smeared slice to be used as the bottom of the sandwich!
  bottomSliceWithPB : SliceOfBread
  bottomSliceWithPB = pr₁ (pr₁ step2)

  -- Get another slice of bread and smear it with jelly, using the same knife as before.
  step3 : Σ _ ꞉ SliceOfBread × Utensil , _
  step3 =
    let
      jellyKnife : Utensil
      jellyKnife =
        let
          -- The knife is now clean after having spread all its peanut butter on the other slice.
          usedKnife : Utensil
          usedKnife = pr₂ (pr₁ step2)
          j : CondimentJar
          j = pr₁ (fetchCondimentJar jelly)
        in pr₁ (pr₁ (loadFrom (usedKnife , (refl knife , refl)) (pr₁ (openJar j) , (jelly , refl) , refl open')))
      topSlice : SliceOfBread
      topSlice = pr₁ (fetchSliceOfBread wholeGrain)
    in
      smearSliceOfBread
      (jellyKnife , (refl knife , (refl knife , jelly) , refl))
      bottom
      (topSlice , (inr (refl bottom , refl)))

  -- Our successfully smeared slice to be used as the top of the sandwich!
  topSliceWithJelly : SliceOfBread
  topSliceWithJelly = pr₁ (pr₁ step3)

I broke it down into steps (step1, step2, step3) so it’s a bit easier to follow. The important part is we have our sandwich:

sandwich topSliceWithJelly bottomSliceWithPB (refl , (refl , inl (jelly , refl))) (1 , ⋆)

It has a top slice, a bottom slice, proof that the slices are smeared appropriately, and it’s in 1 piece.

For most of you, it’s probably really difficult to try reading a foreign language in an unfamiliar paradigm. Don’t worry about piecing together every little bit. What you should be looking at are the types of the variables and what things they refer to. For example:

usedKnife : Utensil
usedKnife = pr₂ (pr₁ step2)

The first line tells us usedKnife is a utensil. And, in the second line, we can see it comes from step2, which involved a knife being used to smear a slice of bread with peanut butter, as the comment says. So, now we know usedKnife is not just any utensil, but a knife, and the one we used previously.

See the full code on GitHub: https://github.com/SlimTim10/simple-sandwich

Conclusion

I hope you enjoyed this exploration with me! Send me a message if you have any comments or feedback. I love to chat about this stuff! Many thanks to Danny for sparking this idea and sharing the journey. Go check out his blog, it’s a real treat to read.

I wrote this as a sort of response to a post by my friend Danny Fekete. For any of this to make sense, you’ll want to read his post first. These are my thoughts related to the ideas Danny brought up as well as Haskell code inspired by Danny’s Ruby code. I would describe the subject as programming philosophy.

Food for Thought

The point of the “exact instructions challenge” shown in this video is to explain to kids (or any non-programmers) what it’s like to write a computer program to solve a task. I used to think this was a good explanation, but now I’ve changed my mind. What’s being said is that giving a computer instructions to solve a task is challenging because you need to be very precise. The computer is dumb and won’t fill in the gaps; it will not necessarily do what you have in mind if you give it vague instructions. Instead, it does the wrong thing or produces an error. So let’s think about this. Why is it different from giving a human vague instructions? Well, a human can fill in the blanks. Why? Because they have the same context as the instruction-giver and both minds abstract the details. If a human did not have the proper context, they would do the task wrong, like the dad in the video. So, the dad is not acting specifically like a computer but rather any receiver with improper context that is attempting the task anyway. Realistically, if a computer has improper context to perform an instruction, it will produce an error rather than try to do it and fail. In whatever programming language you choose, if you try to run the function makeSandwich and that function doesn’t exist, it will produce an error instead of trying to make a sandwich (whatever it means for a computer to make a sandwich…).

So really, what we’re talking about here is context and abstraction, not necessarily humans vs computers. Now you think I’m being pedantic. True, computers are usually the ones with less context and can’t do abstraction on their own. But programmers are the ones deciding what context is needed! If a language is made at a higher level of abstraction than another, it may need less context than the other to accomplish the same task. For example, in Haskell, I can write putStrLn (unwords ["Hello,", "world!"]) to print “Hello, world!”, but in C, I would have to write a lot more code (giving more context about how to make an array into a sentence of words). The fact is, no programmer writes code from scratch. Everyone is building upon other work, even if you’re including the language’s standard library. In fact, if I take the effort to write the unwords function in C, then the resulting code is not too different from Haskell: printf("%s", unwords((char**){"Hello,", "world!"}, 2));.

In the end, if someone (it doesn’t matter who) has made a makeSandwich function and it makes a sandwich (somehow…), I can tell the computer to run that function and I don’t need to give it extra information. The same as telling a human who I trust to make a sandwich, “make me a sandwich”.

Now that we have sophisticated AI (demonstrated by tools like ChatGPT), computers actually have as much context as the average person for many problems. The AI can do spoken language processing that appears to be on par with humans. I can give it a problem to solve, written in plain English, and it will give a solution! Many people would be fooled into thinking they’re chatting with a human.

Programming a Sandwich

That said, let’s say we want to demonstrate what it would be like to program the computer to make a sandwich anyway. In Danny’s post, he wrote a great, complete example in Ruby code. After reading through it, it brings up some interesting points to talk about:

• Error handling
• Mutability and state
• Programming paradigms (object-oriented programming, functional programming)
• Type theory

Fortunately for me, Danny already handled the hardest part: deciding what functionality to include in the sandwich-making code. After all, we can’t expect the computer to make a real sandwich in the end, so one has to (somewhat arbitrarily) decide what a valid solution requires.

For my own exploration, I decided to take the following steps:

• Translate Danny’s OOP (object-oriented programming) solution into Haskell
• Write an idiomatic Haskell solution
• Write a Haskell solution using type-level programming
• Write an Agda solution

Before getting to the code, I want to express some thoughts about programming concepts.

Error Handling

Deciding how to handle errors is a notoriously tricky problem in programming. We have to think about what kind of errors our code may encounter. Are they logic-breaking errors, in which case we want our app to print a message and quit running when it encounters one? Or are they more like warnings, where we can print a message to the user and allow the code to continue running? Should we even handle them at all or just let the program break when it may? Maybe we should mix and match? Can we reduce the possible errors some other way?

Before I could write any Haskell solution to the sandwich-making problem, I had to decide how to handle errors. After all, many things can go wrong along the way, like attempting to put a knife in a closed jar of peanut butter.

Because Haskell is a purely functional language, every function is considered either to be “pure” or in a monad (such as “IO”). Using the monad concept is how Haskell gets around the “impure” or “side effect” capability while retaining a pure mathematical foundation. It is favourable to keep as many functions pure as possible, so handling errors in a pure way would be ideal.

Breaking errors

One option to handle errors is to simply break execution and print an error message whenever one happens. In Haskell, this would be done using the built-in error function, which can be used in any function. But this comes with caveats:

• We can’t know which functions may produce an error by looking at their type signature.
• We can’t recover from errors.

Exceptions

Another option is to throw exceptions. Then we can catch errors, but it comes with a big caveat:

• Every function that may throw an exception (or include another function that may throw an exception) must be in the IO monad. That means virtually all the code has to live in the IO monad, and we don’t have any pure functions.

Maybe

A more idiomatic option in Haskell is to use the Maybe type. Any function that might produce an error returns a Maybe a value, which is either Nothing or Just a, where a is any type. For example,

relinquishContents :: Jar -> Maybe (Jar, Condiment)

This version of relinquishContents takes a Jar and returns either Nothing if it fails (because the jar is closed or empty) or a pair (Jar, Condiment) of a new empty Jar and a Condiment. The problem with using Maybe is we don’t have any message attached to the error side; we just have Nothing. So we know something went wrong, but we don’t know what it is.

Either

Finally, the solution I settled on is the other idiomatic option in Haskell: the Either type. It’s almost the same as Maybe, except its values are Left a and Right b, where a and b are any types. This way, we have,

relinquishContents :: Jar -> Either String (Jar, Condiment)

In the error case, relinquishContents returns a Left String (such as Left "The jar is closed and knife-impermeable."). In the good case, it returns a Right (Jar, Condiment). In other words, we either have an error message or a good return value.

Taking this path, every function that might produce an error must return an Either type, which allows us to keep most of the code pure. Also, we have no choice but to write code which handles the errors where they may occur. We can’t simply skip over the fact that a function may produce an error; we have to handle both sides of the result: Left and Right.

Mutability and State

In OOP, it’s common to make an instance of an object with some properties and then mutate its properties along the way. For example, we may have a CondimentJar with a contents property that starts off as some string, like “Peanut Butter”. When we want to empty the jar, we set its contents property to nil, effectively mutating the state of the jar.

This can often make code easy to write but harder to follow. For example, in the Ruby solution’s Sandwich class, I didn’t know what the build! method was going to do when I first saw it. Based on the name, I figured it would build a sandwich and mutate the instance somehow. I didn’t know if it would also mutate something inside the sandwich, like the slices of bread. Without reading the rest of the code, how could I know what other variables might get mutated down the line? To discover the function’s purpose and result, I had to read its entire body. In Haskell, I only need to read a function’s type signature to know exactly what its capabilities are.

In pure functional code, there’s no such thing as mutability. When we have a CondimentJar with its contents set to “Peanut Butter”, we can’t simply change that jar. It will always have peanut butter as its contents. Instead of mutating the jar’s state, we must make a new jar which is a copy of the first one, but with its contents set to a different value.

To people less familiar with the concept of immutability, this may seem like a burden, and sometimes it is! But really, it’s just a different perspective on writing code. Instead of keeping track of every variable and its current state at any point in the code, immutability ensures that no variables can ever change, so we can easily discern their value.

Now, this presents us with a philosophical problem in the sandwich-making context. What sense does it make to have a jar which is always full of peanut butter and a knife which is always clean, and when we put them to use we have a new empty jar and a new loaded knife? And does it make sense that we still have access to the old objects? The way I see it, we can think of this in different ways.

In one way, we can say we simply don’t care that it doesn’t represent the real world accurately and as long as we don’t make use of the old objects after we use them, we’re not doing anything we couldn’t do in reality. We just have to always use the latest version of each object.

Another way to think about it is that having access to the old objects is like being able to travel through time. We can think of every variable as being in a particular snapshot of the universe, which we can always go back to. However, this idea breaks down when we can access a new object and its older counterpart simultaneously, which is kind of like having multiple universes that can interact (like the Marvel multiverse).

The most accurate representation of state in a pure functional context is to keep all stateful things in a variable that must be passed as an argument to any function that may update state. This is like passing around the universe (or at least, the important things in it) so we only have access to one version of it at any point in time. In Haskell, there are libraries which handle this in a monad. Then we can write code which looks like we’re updating state, but anything that involves state must be inside the state monad.

In my code, I opted for the first approach; simply ignore the problem! I figure the sandwich-making is represented well enough and the code is simpler to understand.

Haskell Solution - OOP Translation

Since Haskell is a functional language, the following Haskell code is not idiomatic. It is a translation of the object-oriented Ruby solution. Similarly to how we might translate a poem from Portuguese to English word-for-word, the result may have proper grammar and spelling, but the English translation won’t sound poetic like it would if it were composed in English from the start.

Condiment.hs

module Condiment where

type Condiment = String

data OpenOrClosed = Open | Closed
  deriving (Eq)

data Jar = Jar
  { contents :: Maybe Condiment
  , lid :: OpenOrClosed
  }

newJar :: Condiment -> Jar
newJar c = Jar
  { contents = Just c
  , lid = Closed
  }

isEmpty :: Jar -> Bool
isEmpty Jar{contents=Nothing} = True
isEmpty _ = False

hasStuff :: Jar -> Bool
hasStuff = not . isEmpty

isClosed :: Jar -> Bool
isClosed Jar{lid=Closed} = True
isClosed _ = False

closeJar :: Jar -> Jar
closeJar cj = cj {lid=Closed}

isOpen :: Jar -> Bool
isOpen = not . isClosed

openJar :: Jar -> Jar
openJar cj = cj {lid=Open}

relinquishContents :: Jar -> Either String (Jar, Condiment)
relinquishContents cj@Jar{contents=Just c}
  | isClosed cj = Left "The jar is closed and knife-impermeable."
  | isEmpty cj = Left "The jar is empty. How disappointing."
  | otherwise = Right (cj{contents=Nothing}, c)

In this OOP translation, a Haskell record is defined for each of its Ruby class counterpart. In idiomatic Haskell, records are used frequently but not to represent classes/objects in such a way. And the small functions like isClosed correspond to OOP methods or property accessors, which would be replaced by pattern matching in idiomatic Haskell.

In Condiment.hs, the newJar function acts like an object constructor in OOP (e.g., Ruby’s initialize method). It takes a Condiment to tell it what the contents of the jar should be and gives back a closed jar full of that condiment.

-- Haskell
let pb = Condiment.newJar "Peanut Butter"

# Ruby
pb = CondimentJar.new("Peanut Butter")

As discussed above about error handling, relinquishContents returns an Either type which may either be an error message (Left String) or a pair of a new empty jar and a condiment (Right (Jar, Condiment)).

relinquishContents :: Jar -> Either String (Jar, Condiment)
relinquishContents cj@Jar{contents=Just c}
  | isClosed cj = Left "The jar is closed and knife-impermeable."
  | isEmpty cj = Left "The jar is empty. How disappointing."
  | otherwise = Right (cj{contents=Nothing}, c)

Knife.hs

module Knife where

import qualified Condiment

data Knife = Knife
  { contents :: Maybe Condiment.Condiment
  }

new :: Knife
new = Knife {contents=Nothing}

isClean :: Knife -> Bool
isClean Knife {contents=Nothing} = True
isClean _ = False

clean :: Knife -> Knife
clean k = k {contents=Nothing}

isLoaded :: Knife -> Bool
isLoaded = not . isClean

loadFrom :: Knife -> Condiment.Jar -> Either String (Knife, Condiment.Jar)
loadFrom k cj
  | isLoaded k = Left "This knife is already loaded. Don't mix your condiments!"
  | otherwise = uncurry load <$> Condiment.relinquishContents cj
  where
    load cj' c = (k {contents=Just c}, cj')

Interesting to note here is the decision to include loadFrom in the Knife.hs module. It seemed right to put it here because the OOP version has loadFrom as a method of the Knife object. But in this Haskell version, loadFrom is a pure function that happens to take a Knife and a Condiment.Jar as two arguments, so it doesn’t need to belong in any specific module. It would work just as well to put it in Main.hs. In fact, the same could be said for any of the functions. The choice to put them in a particular module is somewhat arbitrary; it simply makes sense intuitively to bundle them together based on context. In the case of loadFrom, it would make just as much sense to put it in Condiment.hs or Main.hs.

Bread.hs

module Bread where

import qualified Condiment
import qualified Knife

data Surface = Surface
  { contents :: Maybe Condiment.Condiment
  }

newSurface :: Surface
newSurface = Surface
  { contents = Nothing
  }

surfaceIsPlain :: Surface -> Bool
surfaceIsPlain Surface {contents=Nothing} = True
surfaceIsPlain _ = False

surfaceIsSmeared :: Surface -> Bool
surfaceIsSmeared = not . surfaceIsPlain

data Slice = Slice
  { top :: Surface
  , bottom :: Surface
  }

newSlice :: Slice
newSlice = Slice
  { top = newSurface
  , bottom = newSurface
  }

sliceIsPlain :: Slice -> Bool
sliceIsPlain Slice {top=t, bottom=b}
  = surfaceIsPlain t && surfaceIsPlain b

sliceIsSmeared :: Slice -> Bool
sliceIsSmeared = not . sliceIsPlain

smearSurface :: Knife.Knife -> Surface -> Either String (Knife.Knife, Surface)
smearSurface k s
  | surfaceIsSmeared s = Left "This surface was already smeared!"
  | Knife.isClean k = Left "This knife is too clean to smear with."
  | otherwise = Right (Knife.clean k, s {contents=Knife.contents k})

Sandwich.hs

module Sandwich where

import qualified Bread
import qualified Condiment
import qualified Knife

import qualified Data.Maybe as Maybe
import qualified Data.List as L

data Sandwich = Sandwich
  { slices :: [Bread.Slice]
  , built :: Bool
  , isCut :: Bool
  }

new :: [Bread.Slice] -> Sandwich
new slices = Sandwich
  { slices = slices
  , built = False
  , isCut = False
  }

flavours :: Sandwich -> [Condiment.Condiment]
flavours = concat . map sliceFlavours . slices
  where
    sliceFlavours :: Bread.Slice -> [Condiment.Condiment]
    sliceFlavours = Maybe.catMaybes . map Bread.contents . sequence [Bread.top, Bread.bottom]

showFlavours :: Sandwich -> String
showFlavours = f . flavours
  where
    f :: [Condiment.Condiment] -> String
    f cs
      | length cs == 2 = L.intercalate " and " cs
      | otherwise = L.intercalate ", " (init cs) ++ ", and " ++ last cs

isReadyToEat :: Sandwich -> Bool
isReadyToEat sw = built sw && isCut sw

build :: Sandwich -> Either String Sandwich
build sw
  | built sw = Left "It's already a glorious tower of food!"
  | length (slices sw) < 2 = Left "Not enough slices"
  | outsideSmeared = Left "This sandwich would be icky to hold."
  | tooPlain = Left "This sandwich might actually be a loaf."
  | otherwise = Right (sw {built=True})
  where
    bottomSmeared :: Bool
    bottomSmeared = Bread.surfaceIsSmeared . Bread.bottom . head $ slices sw

    topSmeared :: Bool
    topSmeared = Bread.surfaceIsSmeared . Bread.top . last $ slices sw

    outsideSmeared :: Bool
    outsideSmeared = length (slices sw) >= 2 && (bottomSmeared || topSmeared)

    tooPlain :: Bool
    tooPlain = any Bread.sliceIsPlain . init . tail $ slices sw

cut :: Sandwich -> Knife.Knife -> Either String Sandwich
cut sw k
  | (not . built) sw = Left "Build the sandwich and then cut it in one glorious stroke."
  | Knife.isLoaded k = Left "No! You'll get the edge all yucky with that knife."
  | isCut sw = Left "One cut will do."
  | otherwise = Right (sw {isCut=True})

Main.hs

module Main where

import qualified Condiment
import qualified Knife
import qualified Bread
import qualified Sandwich

main :: IO ()
main = do
  let bread = replicate 5 Bread.newSlice
  let pb = Condiment.newJar "Peanut Butter"
  let jelly = Condiment.newJar "Jelly"
  let knife = Knife.new

  -- First attempt. Didn't open the jar of peanut butter.
  either printError putStrLn $ do
    (pbKnife, pbEmpty) <- knife `Knife.loadFrom` pb -- Problem
    (usedKnife1, surface1) <- Bread.smearSurface pbKnife . Bread.top . head $ bread
    (jellyKnife, jellyEmpty) <- knife `Knife.loadFrom` Condiment.openJar jelly
    (usedKnife2, surface2) <- Bread.smearSurface jellyKnife . Bread.bottom . last $ bread
    let sw = Sandwich.new bread
    Sandwich.build sw
    return "Sandwich made!"

  -- Next attempt. Used too much bread inside.
  either printError putStrLn $ do
    (pbKnife, pbEmpty) <- knife `Knife.loadFrom` Condiment.openJar pb
    (usedKnife1, surface1) <- Bread.smearSurface pbKnife . Bread.top . head $ bread
    (jellyKnife, jellyEmpty) <- knife `Knife.loadFrom` Condiment.openJar jelly
    (usedKnife2, surface2) <- Bread.smearSurface jellyKnife . Bread.bottom . last $ bread
    let sw = Sandwich.new bread
    Sandwich.build sw -- Problem
    return "Sandwich made!"

  -- Successful sandwich making!
  either printError putStrLn $ do
    (pbKnife, pbEmpty) <- knife `Knife.loadFrom` Condiment.openJar pb
    (usedKnife1, surface1) <- Bread.smearSurface pbKnife . Bread.top . head $ bread
    (jellyKnife, jellyEmpty) <- knife `Knife.loadFrom` Condiment.openJar jelly
    (usedKnife2, surface2) <- Bread.smearSurface jellyKnife . Bread.bottom . last $ bread
    let sw = Sandwich.new [head bread, last bread]
    Sandwich.build sw
    return "Sandwich made!"
  where
    printError :: String -> IO ()
    printError e = putStrLn ("Error: " ++ e)

This module, Main.hs, is where things get more interesting. In Haskell, we always need a main function that lives in the IO (input/output) monad, otherwise we would never be able to see any results from running our application. The functions that return an Either type for errors are also used as a monad. Haskell’s do notation uses monadic operations which end up looking like imperative instructions. It’s really just syntactic sugar for doing things sequentially and updating context as it goes. The interesting thing is that each code block containing a sandwich-making attempt acts similarly to try-catch exception handling in other languages. If anything goes wrong, that is, if any function returns a Left value, it gets printed with “Error:” before it. If all goes right, it prints the result of the block: “Sandwich made!”.

Again, there’s nothing stopping us from using pbKnife more than once because we’re not keeping track of any state, so some care must be taken when making a sandwich.

In the end, I think this version is quite readable (if you know Haskell), though the modules contain more functions than needed, and the custom types are all records instead of more intuitive types, as in the following version.

What is a sandwich?

Something about the Sandwich type (or Ruby class) doesn’t sit well with me. In my mind, it doesn’t make sense for a sandwich to have a built property that says whether the sandwich is built correctly or not. What would it mean to have a sandwich that is not built? That sounds like something that is not a sandwich, which shouldn’t be part of the definition of what a sandwich is. If it is possible to make an instance of a sandwich that is not a proper sandwich, maybe the type/class/definition of a sandwich needs more refining. In this definition, a sandwich is allowed to have any number of slices. Wouldn’t it make more sense for a sandwich to require at least two slices of bread? Or, even more accurately, a sandwich requires exactly two slices of bread (any inner slices of bread can be considered part of the sandwich–unless that’s all it has, in which case it is a loaf). I see it as partway to an accurate definition of a sandwich but stopped short.

Haskell Solution - Idiomatic

In this version, I attempted a more idiomatic Haskell solution, using fewer records, more pattern matching, and more features of types.

I also took some liberties to reframe parts of the problem. In Danny’s code, I noticed a validation to make sure we’re using a knife where another utensil wouldn’t work.

def smear!(knife:, surface:)
    unless knife.is_a?(Knife)
      raise InvalidKnifeError, "That's not hygienic."
    end
# ...

I decided if we’re going to be checking that we’re using a knife, we may as well include other utensils. Otherwise, the only kind of utensil the program knows about is a knife. In Haskell, we never need to check whether a value is of a particular type; that’s made explicit by static typing, and the compiler does the type-checking work.

I took a similar approach to bread. We may also include different flavours of bread to make things more interesting.

Because this version is idiomatic code, it’s also much shorter, so I put it all in a single module.

Main.hs

module Main where

data UtensilShape = Knife | Spoon | Fork
  deriving (Show, Eq)

data Utensil = Utensil
  { uShape :: UtensilShape
  , uCondiment :: Maybe Condiment
  }
  deriving (Show)

fetchUtensil :: UtensilShape -> Utensil
fetchUtensil shape = Utensil
  { uShape = shape
  , uCondiment = Nothing
  }

data Condiment = PeanutButter | Jelly
  deriving (Show, Eq)

data OpenOrClosed = Open | Closed
  deriving (Show, Eq)

data CondimentJar = CondimentJar
  { cjCondiment :: Maybe Condiment
  , cjLid :: OpenOrClosed
  }
  deriving (Show)

fetchCondimentJar :: Condiment -> CondimentJar
fetchCondimentJar c = CondimentJar
  { cjCondiment = Just c
  , cjLid = Closed
  }

loadFrom :: Utensil -> CondimentJar -> Either String (Utensil, CondimentJar)
loadFrom _ CondimentJar{cjLid=Closed} = Left "The jar is closed and knife-impermeable."
loadFrom _ CondimentJar{cjCondiment=Nothing} = Left "The jar is empty. How disappointing."
loadFrom Utensil{uShape=Fork} _ = Left "Forks aren't the right shape for condiments."
loadFrom u cj@CondimentJar{cjCondiment=Just c}
  = Right (u { uCondiment = Just c }, cj { cjCondiment = Nothing })

openJar :: CondimentJar -> CondimentJar
openJar cj = cj { cjLid = Open }

data BreadFlavour = Sourdough | WholeGrain | White
  deriving (Show)

data SliceOfBread = SliceOfBread
  { sobFlavour :: BreadFlavour
  , sobTop :: Maybe Condiment
  , sobBottom :: Maybe Condiment
  }
  deriving (Show)

fetchSliceOfBread :: BreadFlavour -> SliceOfBread
fetchSliceOfBread flavour = SliceOfBread
  { sobFlavour = flavour
  , sobTop = Nothing
  , sobBottom = Nothing
  }

data Surface = Top | Bottom
  deriving (Show, Eq)

smearSliceOfBread :: Utensil -> Surface -> SliceOfBread -> Either String (SliceOfBread, Utensil)
smearSliceOfBread u surface slice
  | uShape u /= Knife = Left "You can't smear with that!"
  | uCondiment u == Nothing = Left "This knife is too clean to smear with."
  | surface == Top && sobTop slice /= Nothing = Left "This surface was already smeared!"
  | surface == Bottom && sobBottom slice /= Nothing = Left "This surface was already smeared!"
  | otherwise = Right (smearedSlice, cleanUtensil)
  where
    smearedSlice
      | surface == Top = slice { sobTop = uCondiment u }
      | surface == Bottom = slice { sobBottom = uCondiment u }
    cleanUtensil = u { uCondiment = Nothing}

data Sandwich = Sandwich
  { swBottom :: SliceOfBread
  , swTop :: SliceOfBread
  , swPieces :: [(SliceOfBread, SliceOfBread)]
  }
  deriving (Show)

makeSandwich :: SliceOfBread -> SliceOfBread -> Either String Sandwich
makeSandwich bottom top
  | sobTop bottom == Nothing && sobBottom top == Nothing = Left "This sandwich might actually be a loaf."
  | sobTop top /= Nothing || sobBottom bottom /= Nothing = Left "This sandwich would be icky to hold."
  | otherwise = Right Sandwich { swBottom = bottom, swTop = top, swPieces = [(bottom, top)] }

-- A sandwich is always cut through all the pieces, doubling them all
cutSandwich :: Utensil -> Sandwich -> Either String Sandwich
cutSandwich u sw
  | uShape u == Fork || uShape u == Spoon = Left "You can't cut a sandwich with that!"
  | uCondiment u /= Nothing = Left "No! You'll get the edge all yucky with that knife."
  | otherwise = Right sw { swPieces = newPieces }
  where
    newPieces = concat [swPieces sw, swPieces sw]

main :: IO ()
main = do
  let knife = fetchUtensil Knife
  let pb = fetchCondimentJar PeanutButter
  let jelly = fetchCondimentJar Jelly

  -- First attempt. Didn't open the jar of peanut butter.
  either printError putStrLn $ do
    (pbKnife, emptyPB) <- knife `loadFrom` pb -- Problem
    return "Sandwich made!"

  -- Next attempt. Too plain.
  either printError putStrLn $ do
    (pbKnife, emptyPB) <- knife `loadFrom` openJar pb
    (jellyKnife, emptyJelly) <- knife `loadFrom` openJar jelly
    let bottomSlice = fetchSliceOfBread Sourdough
    let topSlice = fetchSliceOfBread WholeGrain
    sw <- makeSandwich bottomSlice topSlice
    return "Sandwich made!"

  -- Successful sandwich making!
  either printError putStrLn $ do
    (pbKnife, emptyPB) <- knife `loadFrom` openJar pb
    (jellyKnife, emptyJelly) <- knife `loadFrom` openJar jelly
    let bottomSlice = fetchSliceOfBread Sourdough
    let topSlice = fetchSliceOfBread WholeGrain
    (bottomSliceWithPB, cleanKnife) <- smearSliceOfBread pbKnife Top bottomSlice
    (topSliceWithJelly, cleanKnife) <- smearSliceOfBread jellyKnife Bottom topSlice
    sw <- makeSandwich bottomSliceWithPB topSliceWithJelly
    return "Sandwich made!"
  where
    printError :: String -> IO ()
    printError e = putStrLn ("Error: " ++ e)

To replace the new functions from the OOP-translated version, I included functions like fetchCondimentJar, which act similarly. The different naming convention (“fetch-” instead of “new-”) is because I started thinking of the instance-creating functions as being analogous to fetching something from the kitchen. When it’s time to get a condiment jar, we can use fetchCondimentJar to fetch one of the given condiments. Interestingly, these idiomatic functions still behave much like OOP constructors.

I also merged the previous Slice and Bread into a single type, SliceOfBread:

data SliceOfBread = SliceOfBread
  { sobFlavour :: BreadFlavour
  , sobTop :: Maybe Condiment
  , sobBottom :: Maybe Condiment
  }