Creates a new pair, whose contents are given by two subexpressions.

We can add two expressions together, but since we don't have an Expression type (yet), we don't know what type the left- and right-hand sides should h

Each term type should implement this trait to define how it should be evaluated. If the term has any subexpressions, it should use `eval_subexpr` to

Well that was easy. (Not really! Don't worry, we'll run into wrinkles.)

Each kind of term in our language should implement this trait to define how it's evaluated.

We can use an enum to represent all of the different kinds of term that can appear in our toy language.

This is the closest we can get: we create a new Expression type, containing each of the new kinds of term, and use a wrapper variant at the end to inc

An Expression represents the AST of one of our mini-languages. It has a `Signature` associated type, which is a `Sum` of all of the possible terms in

Extract the first element of a pair.

I'm going to make the bold claim that most of Swierstra §6 isn't relevant in Rust — we don't typically use monads to express stateful computations, we

Instead of having a single Expression enum, with different variants for each kind of term, we create a separate type for each kind of term. We're goi

The simplest memory store is just a struct containing the current contents.

First a type for the new term

We don't have a trait that we can reuse for the evaluation rules for First and Second, like we could with std::ops::Add for our Add term. So let's ma

If you only want to read the contents of the memory, you can get away with non-mutable access to it.

Extract the second element of a pair.

This is how we'll create the different Expression types from ch01! This corresponds to the :+: "coproduct" operator from the paper.