Continuations, All The Way Down Tim Humphries Ambiata - - PowerPoint PPT Presentation
Continuations, All The Way Down Tim Humphries Ambiata @thumphriees teh.id.au Hi! My names Tim. Im an engineer at Ambiata, here in Sydney. I gave my talk the wrong title. Im not going to spend much time talking about CPS, shift/reset,
Tim Humphries Ambiata @thumphriees teh.id.au
Hi! My name’s Tim. I’m an engineer at Ambiata, here in Sydney. I gave my talk the wrong title. I’m not going to spend much time talking about CPS, shift/reset, or call/cc. I’m just going to be using functions to solve problems. I should have called it…
Tim Humphries Ambiata @thumphriees teh.id.au
We’re going to use functions to improve expressions. We’re going to make typed interfaces for these improvements.
(append)
The first function I want to talk about is append. Append is my favourite function.
Here I have two expressions that use append. Are these expressions the same? If we ask GHC the wrong question, it might say yes. These expressions evaluate to the same value, but they get there very differently. It’s easier to understand why when we draw them as trees. In these trees, the leaves are literal values, the branches are functions, and the edges are function application. We see that xs is a tree that leans to the right. It’s right-associated. We see that ys, which is left-associated, is a tree that leans to the left. This changes the way they evaluate.
Here I have two expressions that use append. Are these expressions the same? If we ask GHC the wrong question, it might say yes. These expressions evaluate to the same value, but they get there very differently. It’s easier to understand why when we draw them as trees. In these trees, the leaves are literal values, the branches are functions, and the edges are function application. We see that xs is a tree that leans to the right. It’s right-associated. We see that ys, which is left-associated, is a tree that leans to the left. This changes the way they evaluate.
Here I have two expressions that use append. Are these expressions the same? If we ask GHC the wrong question, it might say yes. These expressions evaluate to the same value, but they get there very differently. It’s easier to understand why when we draw them as trees. In these trees, the leaves are literal values, the branches are functions, and the edges are function application. We see that xs is a tree that leans to the right. It’s right-associated. We see that ys, which is left-associated, is a tree that leans to the left. This changes the way they evaluate.
Here I have two expressions that use append. Are these expressions the same? If we ask GHC the wrong question, it might say yes. These expressions evaluate to the same value, but they get there very differently. It’s easier to understand why when we draw them as trees. In these trees, the leaves are literal values, the branches are functions, and the edges are function application. We see that xs is a tree that leans to the right. It’s right-associated. We see that ys, which is left-associated, is a tree that leans to the left. This changes the way they evaluate.
Here I have two expressions that use append. Are these expressions the same? If we ask GHC the wrong question, it might say yes. These expressions evaluate to the same value, but they get there very differently. It’s easier to understand why when we draw them as trees. In these trees, the leaves are literal values, the branches are functions, and the edges are function application. We see that xs is a tree that leans to the right. It’s right-associated. We see that ys, which is left-associated, is a tree that leans to the left. This changes the way they evaluate.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
Both of these expressions have a spine comprised of two appends. If we take a look at the implementation of append, we see it never touches the right branch. It walks down the left branch until it hits an element. It returns that element in a cons. The rest of the list is a recursive call to append. i.e. until the list on the left is eliminated, the tree’s spine stays the same. With this in mind, let’s see how they evaluate. XS, on the left, can pull an element out in constant time. YS, on the right, takes an extra step.
This isn’t much of a problem for our little expression. However, for deeper append trees, it could lead to substantial overhead. Here we have two larger append trees, associated right and associated left. They have the same spine, three appends. The RHS is significantly worse. Almost twice as many operations.
This isn’t much of a problem for our little expression. However, for deeper append trees, it could lead to substantial overhead. Here we have two larger append trees, associated right and associated left. They have the same spine, three appends. The RHS is significantly worse. Almost twice as many operations.
This isn’t much of a problem for our little expression. However, for deeper append trees, it could lead to substantial overhead. Here we have two larger append trees, associated right and associated left. They have the same spine, three appends. The RHS is significantly worse. Almost twice as many operations.
worse
(additional 30-odd steps)
This isn’t much of a problem for our little expression. However, for deeper append trees, it could lead to substantial overhead. Here we have two larger append trees, associated right and associated left. They have the same spine, three appends. The RHS is significantly worse. Almost twice as many operations.
A bad, left-associated append might be created without our knowledge. A beginner will encounter this when using Writer. Writer expects a Monoid, and Lists are the most popular Monoid. Behind every bind is an append. So, the associativity of our monadic code suddenly matters. This is a particularly bad expression. It builds a deeply-left associated bind, then calls tell. This leads to a left-biased tree, where the spine is all binds. When we run the writer, we get a left-biased append, with the same structure.
A bad, left-associated append might be created without our knowledge. A beginner will encounter this when using Writer. Writer expects a Monoid, and Lists are the most popular Monoid. Behind every bind is an append. So, the associativity of our monadic code suddenly matters. This is a particularly bad expression. It builds a deeply-left associated bind, then calls tell. This leads to a left-biased tree, where the spine is all binds. When we run the writer, we get a left-biased append, with the same structure.
snd . runWriter
A bad, left-associated append might be created without our knowledge. A beginner will encounter this when using Writer. Writer expects a Monoid, and Lists are the most popular Monoid. Behind every bind is an append. So, the associativity of our monadic code suddenly matters. This is a particularly bad expression. It builds a deeply-left associated bind, then calls tell. This leads to a left-biased tree, where the spine is all binds. When we run the writer, we get a left-biased append, with the same structure.
snd . runWriter
A bad, left-associated append might be created without our knowledge. A beginner will encounter this when using Writer. Writer expects a Monoid, and Lists are the most popular Monoid. Behind every bind is an append. So, the associativity of our monadic code suddenly matters. This is a particularly bad expression. It builds a deeply-left associated bind, then calls tell. This leads to a left-biased tree, where the spine is all binds. When we run the writer, we get a left-biased append, with the same structure.
awful
When we run this as a benchmark, we see performance is pathological.
(compose)
I’m going to solve this problem using the greatest function of all, compose.
What I want to do is suspend an append. If we look at the type of a suspended append, we see it’s a function, expecting another list. We can finalise this suspended append by applying it to the empty list. We can compose two suspended appends together. We can finalise this pipeline the same way. Note how the appends have composed together.
suspended append
What I want to do is suspend an append. If we look at the type of a suspended append, we see it’s a function, expecting another list. We can finalise this suspended append by applying it to the empty list. We can compose two suspended appends together. We can finalise this pipeline the same way. Note how the appends have composed together.
suspended append
What I want to do is suspend an append. If we look at the type of a suspended append, we see it’s a function, expecting another list. We can finalise this suspended append by applying it to the empty list. We can compose two suspended appends together. We can finalise this pipeline the same way. Note how the appends have composed together.
suspended append
What I want to do is suspend an append. If we look at the type of a suspended append, we see it’s a function, expecting another list. We can finalise this suspended append by applying it to the empty list. We can compose two suspended appends together. We can finalise this pipeline the same way. Note how the appends have composed together.
suspended append
What I want to do is suspend an append. If we look at the type of a suspended append, we see it’s a function, expecting another list. We can finalise this suspended append by applying it to the empty list. We can compose two suspended appends together. We can finalise this pipeline the same way. Note how the appends have composed together.
suspended append
What I want to do is suspend an append. If we look at the type of a suspended append, we see it’s a function, expecting another list. We can finalise this suspended append by applying it to the empty list. We can compose two suspended appends together. We can finalise this pipeline the same way. Note how the appends have composed together.
suspended append
What I want to do is suspend an append. If we look at the type of a suspended append, we see it’s a function, expecting another list. We can finalise this suspended append by applying it to the empty list. We can compose two suspended appends together. We can finalise this pipeline the same way. Note how the appends have composed together.
suspended append
What I want to do is suspend an append. If we look at the type of a suspended append, we see it’s a function, expecting another list. We can finalise this suspended append by applying it to the empty list. We can compose two suspended appends together. We can finalise this pipeline the same way. Note how the appends have composed together.
suspended append
What I want to do is suspend an append. If we look at the type of a suspended append, we see it’s a function, expecting another list. We can finalise this suspended append by applying it to the empty list. We can compose two suspended appends together. We can finalise this pipeline the same way. Note how the appends have composed together.
Claim: composed pipelines of appends are always right-associated. Tree got bigger. Definition of function composition: right-associated function application. If we expand through the tree, we see it works for this simple example. We eliminate the compose operator fairly quickly, and are then left with the optimal append chain. You really need to try this trick by hand to get a feel for it, so I won’t linger.
Claim: composed pipelines of appends are always right-associated. Tree got bigger. Definition of function composition: right-associated function application. If we expand through the tree, we see it works for this simple example. We eliminate the compose operator fairly quickly, and are then left with the optimal append chain. You really need to try this trick by hand to get a feel for it, so I won’t linger.
Claim: composed pipelines of appends are always right-associated. Tree got bigger. Definition of function composition: right-associated function application. If we expand through the tree, we see it works for this simple example. We eliminate the compose operator fairly quickly, and are then left with the optimal append chain. You really need to try this trick by hand to get a feel for it, so I won’t linger.
Claim: composed pipelines of appends are always right-associated. Tree got bigger. Definition of function composition: right-associated function application. If we expand through the tree, we see it works for this simple example. We eliminate the compose operator fairly quickly, and are then left with the optimal append chain. You really need to try this trick by hand to get a feel for it, so I won’t linger.
Claim: composed pipelines of appends are always right-associated. Tree got bigger. Definition of function composition: right-associated function application. If we expand through the tree, we see it works for this simple example. We eliminate the compose operator fairly quickly, and are then left with the optimal append chain. You really need to try this trick by hand to get a feel for it, so I won’t linger.
Claim: composed pipelines of appends are always right-associated. Tree got bigger. Definition of function composition: right-associated function application. If we expand through the tree, we see it works for this simple example. We eliminate the compose operator fairly quickly, and are then left with the optimal append chain. You really need to try this trick by hand to get a feel for it, so I won’t linger.
(([1..10] ++) . ([11..20] ++)) . ([21..30] ++) $ []
It still works when we create a left-associated append chain. Compose will reorient everything into the right-biased tree. The tree is even bigger.
(([1..10] ++) . ([11..20] ++)) . ([21..30] ++) $ []
It still works when we create a left-associated append chain. Compose will reorient everything into the right-biased tree. The tree is even bigger.
(([1..10] ++) . ([11..20] ++)) . ([21..30] ++) $ []
substitute
We substitute in for compose.
(([1..10] ++) . ([11..20] ++)) . ([21..30] ++) $ []
We proceed as we did before; we now have a right-biased append chain expecting a final function. We compose again.
(([1..10] ++) . ([11..20] ++)) . ([21..30] ++) $ []
Things have propagated in a way that you may have found surprising. Again, this works because of the way compose is defined. Try it at home.
(([1..10] ++) . ([11..20] ++)) . ([21..30] ++) $ []
We get the good tree at the end. Success!
Monoid w => Monad (Writer w a)
We can’t use functions in a Writer, so we haven’t really fixed our problem yet. We need a type.
My new type is called AppendK. It’s just a newtype around suspended append. We hoist a list into AppendK by suspending an append. Partial application. We finalise our pipeline by applying it to the empty list.
My new type is called AppendK. It’s just a newtype around suspended append. We hoist a list into AppendK by suspending an append. Partial application. We finalise our pipeline by applying it to the empty list.
My new type is called AppendK. It’s just a newtype around suspended append. We hoist a list into AppendK by suspending an append. Partial application. We finalise our pipeline by applying it to the empty list.
My new type is called AppendK. It’s just a newtype around suspended append. We hoist a list into AppendK by suspending an append. Partial application. We finalise our pipeline by applying it to the empty list.
suspended append
My new type is called AppendK. It’s just a newtype around suspended append. We hoist a list into AppendK by suspending an append. Partial application. We finalise our pipeline by applying it to the empty list.
suspended append
My new type is called AppendK. It’s just a newtype around suspended append. We hoist a list into AppendK by suspending an append. Partial application. We finalise our pipeline by applying it to the empty list.
suspended append
My new type is called AppendK. It’s just a newtype around suspended append. We hoist a list into AppendK by suspending an append. Partial application. We finalise our pipeline by applying it to the empty list.
suspended append
My new type is called AppendK. It’s just a newtype around suspended append. We hoist a list into AppendK by suspending an append. Partial application. We finalise our pipeline by applying it to the empty list.
suspended append
My new type is called AppendK. It’s just a newtype around suspended append. We hoist a list into AppendK by suspending an append. Partial application. We finalise our pipeline by applying it to the empty list.
Lastly, we need to write an append function. As before, we find composing these functions gives us a valid append operation. This means we get constant-time append. We can then trivially write a monoid instance. We can then use it to solve our problem. We see our microbenchmark has been fixed.
Lastly, we need to write an append function. As before, we find composing these functions gives us a valid append operation. This means we get constant-time append. We can then trivially write a monoid instance. We can then use it to solve our problem. We see our microbenchmark has been fixed.
Lastly, we need to write an append function. As before, we find composing these functions gives us a valid append operation. This means we get constant-time append. We can then trivially write a monoid instance. We can then use it to solve our problem. We see our microbenchmark has been fixed.
Lastly, we need to write an append function. As before, we find composing these functions gives us a valid append operation. This means we get constant-time append. We can then trivially write a monoid instance. We can then use it to solve our problem. We see our microbenchmark has been fixed.
~linear time
Lastly, we need to write an append function. As before, we find composing these functions gives us a valid append operation. This means we get constant-time append. We can then trivially write a monoid instance. We can then use it to solve our problem. We see our microbenchmark has been fixed.
(Benchmark!)
The only list functions we were using were append and mempty. We can generalise AppendK for any Monoid. It might not be an optimisation for all Monoids! Benchmark first.
(fmap)
Time to talk about my second-favourite function, fmap.
Are these two expressions the same? Again, same trick. If we ask GHC the wrong question, it will say yes. We also know they’re equal because we know about the Functor laws. fmap fusion is supposed to be a valid transformation. Let’s draw the trees. Observe that the first tree has two fmap nodes. The second tree has just one. It’s been fused. This changes the way they evaluate.
Are these two expressions the same? Again, same trick. If we ask GHC the wrong question, it will say yes. We also know they’re equal because we know about the Functor laws. fmap fusion is supposed to be a valid transformation. Let’s draw the trees. Observe that the first tree has two fmap nodes. The second tree has just one. It’s been fused. This changes the way they evaluate.
Are these two expressions the same? Again, same trick. If we ask GHC the wrong question, it will say yes. We also know they’re equal because we know about the Functor laws. fmap fusion is supposed to be a valid transformation. Let’s draw the trees. Observe that the first tree has two fmap nodes. The second tree has just one. It’s been fused. This changes the way they evaluate.
Are these two expressions the same? Again, same trick. If we ask GHC the wrong question, it will say yes. We also know they’re equal because we know about the Functor laws. fmap fusion is supposed to be a valid transformation. Let’s draw the trees. Observe that the first tree has two fmap nodes. The second tree has just one. It’s been fused. This changes the way they evaluate.
Are these two expressions the same? Again, same trick. If we ask GHC the wrong question, it will say yes. We also know they’re equal because we know about the Functor laws. fmap fusion is supposed to be a valid transformation. Let’s draw the trees. Observe that the first tree has two fmap nodes. The second tree has just one. It’s been fused. This changes the way they evaluate.
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
tree shape never changes (fmap rebuilds it)
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
Let’s look at the code for fmap of list. Observe, like append, that it recursively calls itself until the list is exhausted. This means that the spine, made out of fmaps, does not change until the list is exhausted. If we step through the left tree, we see it has to traverse every fmap node to produce a single value. The right tree can produce new values in constant time. It probably also saves some heap space.
You might think, why would I care about the number of fmap nodes. You might not, but I do, because I have this really stupid function I want to run. It creates expressions with a huge number of fmaps. This forms a right-degenerate tree, and we need to walk through it pretty aggressively to produce each element.
You might think, why would I care about the number of fmap nodes. You might not, but I do, because I have this really stupid function I want to run. It creates expressions with a huge number of fmaps. This forms a right-degenerate tree, and we need to walk through it pretty aggressively to produce each element.
You might think, why would I care about the number of fmap nodes. You might not, but I do, because I have this really stupid function I want to run. It creates expressions with a huge number of fmaps. This forms a right-degenerate tree, and we need to walk through it pretty aggressively to produce each element.
Claim: we can solve this with function composition. We can make fmap fusion mandatory. This is the type of fmap. We want to suspend the initial value, rather than the map. We want to get the mapping function later. So, let’s flip fmap. I’d like to compose together a single mapping function, before throwing it into an fmap. I’m going to suspend an fmap, but partially applied and flipped. My new type is called MapK. Don’t worry too much about the details, just observe it looks a lot like flip fmap. To lift into MapK, we write a function that grabs the future mapping function (k), and uses fmap to apply it to our initial value. This is the one and only fmap.
Claim: we can solve this with function composition. We can make fmap fusion mandatory. This is the type of fmap. We want to suspend the initial value, rather than the map. We want to get the mapping function later. So, let’s flip fmap. I’d like to compose together a single mapping function, before throwing it into an fmap. I’m going to suspend an fmap, but partially applied and flipped. My new type is called MapK. Don’t worry too much about the details, just observe it looks a lot like flip fmap. To lift into MapK, we write a function that grabs the future mapping function (k), and uses fmap to apply it to our initial value. This is the one and only fmap.
Claim: we can solve this with function composition. We can make fmap fusion mandatory. This is the type of fmap. We want to suspend the initial value, rather than the map. We want to get the mapping function later. So, let’s flip fmap. I’d like to compose together a single mapping function, before throwing it into an fmap. I’m going to suspend an fmap, but partially applied and flipped. My new type is called MapK. Don’t worry too much about the details, just observe it looks a lot like flip fmap. To lift into MapK, we write a function that grabs the future mapping function (k), and uses fmap to apply it to our initial value. This is the one and only fmap.
Claim: we can solve this with function composition. We can make fmap fusion mandatory. This is the type of fmap. We want to suspend the initial value, rather than the map. We want to get the mapping function later. So, let’s flip fmap. I’d like to compose together a single mapping function, before throwing it into an fmap. I’m going to suspend an fmap, but partially applied and flipped. My new type is called MapK. Don’t worry too much about the details, just observe it looks a lot like flip fmap. To lift into MapK, we write a function that grabs the future mapping function (k), and uses fmap to apply it to our initial value. This is the one and only fmap.
Claim: we can solve this with function composition. We can make fmap fusion mandatory. This is the type of fmap. We want to suspend the initial value, rather than the map. We want to get the mapping function later. So, let’s flip fmap. I’d like to compose together a single mapping function, before throwing it into an fmap. I’m going to suspend an fmap, but partially applied and flipped. My new type is called MapK. Don’t worry too much about the details, just observe it looks a lot like flip fmap. To lift into MapK, we write a function that grabs the future mapping function (k), and uses fmap to apply it to our initial value. This is the one and only fmap.
Claim: we can solve this with function composition. We can make fmap fusion mandatory. This is the type of fmap. We want to suspend the initial value, rather than the map. We want to get the mapping function later. So, let’s flip fmap. I’d like to compose together a single mapping function, before throwing it into an fmap. I’m going to suspend an fmap, but partially applied and flipped. My new type is called MapK. Don’t worry too much about the details, just observe it looks a lot like flip fmap. To lift into MapK, we write a function that grabs the future mapping function (k), and uses fmap to apply it to our initial value. This is the one and only fmap.
(the _only_ fmap)
suspended fmap
Claim: we can solve this with function composition. We can make fmap fusion mandatory. This is the type of fmap. We want to suspend the initial value, rather than the map. We want to get the mapping function later. So, let’s flip fmap. I’d like to compose together a single mapping function, before throwing it into an fmap. I’m going to suspend an fmap, but partially applied and flipped. My new type is called MapK. Don’t worry too much about the details, just observe it looks a lot like flip fmap. To lift into MapK, we write a function that grabs the future mapping function (k), and uses fmap to apply it to our initial value. This is the one and only fmap.
To add another map to the chain, we just grab the existing mapping function (k) and compose. ‘g’ here is our outer fmap. We can now write a Functor instance using nothing but our MapK function. Look, no constraints! This is slightly more general than a Functor.
To add another map to the chain, we just grab the existing mapping function (k) and compose. ‘g’ here is our outer fmap. We can now write a Functor instance using nothing but our MapK function. Look, no constraints! This is slightly more general than a Functor.
To add another map to the chain, we just grab the existing mapping function (k) and compose. ‘g’ here is our outer fmap. We can now write a Functor instance using nothing but our MapK function. Look, no constraints! This is slightly more general than a Functor.
To add another map to the chain, we just grab the existing mapping function (k) and compose. ‘g’ here is our outer fmap. We can now write a Functor instance using nothing but our MapK function. Look, no constraints! This is slightly more general than a Functor.
list_add :: Int -> [Int] -> [Int] list_add x xs = toFunctor (list_add' x (fromFunctor xs)) list_add' :: Int -> MapK [] Int -> MapK [] Int list_add' 0 xs = xs list_add' x xs = list_add' (x-1) (fmap (+1) xs)
Now we can rewrite our pathological benchmark to use MapK. We find we’ve eliminated a quadratic factor. (The functions are also quadratic)
list_add :: Int -> [Int] -> [Int] list_add x xs = toFunctor (list_add' x (fromFunctor xs)) list_add' :: Int -> MapK [] Int -> MapK [] Int list_add' 0 xs = xs list_add' x xs = list_add' (x-1) (fmap (+1) xs)
Now we can rewrite our pathological benchmark to use MapK. We find we’ve eliminated a quadratic factor. (The functions are also quadratic)
list_add :: Int -> [Int] -> [Int] list_add x xs = toFunctor (list_add' x (fromFunctor xs)) list_add' :: Int -> MapK [] Int -> MapK [] Int list_add' 0 xs = xs list_add' x xs = list_add' (x-1) (fmap (+1) xs)
fmaps +1 . +1 . +1 …
Now we can rewrite our pathological benchmark to use MapK. We find we’ve eliminated a quadratic factor. (The functions are also quadratic)
(bind)
My next most favourite function, Bind, is up next.
bind associativity matters (sometimes)
From the Writer example, we learned that bind associativity matters sometimes. There can be hidden appends underneath, or worse (recursive definition of bind). My writer example was fixed by reassociating the underlying append. However, we could also just rearrange the binds!
bind associativity matters (sometimes)
awful
From the Writer example, we learned that bind associativity matters sometimes. There can be hidden appends underneath, or worse (recursive definition of bind). My writer example was fixed by reassociating the underlying append. However, we could also just rearrange the binds!
bind associativity matters (sometimes)
From the Writer example, we learned that bind associativity matters sometimes. There can be hidden appends underneath, or worse (recursive definition of bind). My writer example was fixed by reassociating the underlying append. However, we could also just rearrange the binds!
newtype BindK m a = BindK { }
Just like before, we’re going to suspend bind in a function by partially applying it. We can lower back into the target monad by directing that bind pipeline into a return. Note that this is the only return in our resulting expression. The expression will be in monadic normal form. I’ll flesh out the types now, but don’t stress. It’s just the right-hand side of a bind. Just like we had a Monoid for AppendK, and a Functor for MapK, we can build a Monad instance for BindK. Wrapping an interface in functions produces a thing that’s slightly more general than that interface. Don’t worry about the monad instance too much either. If you work it out in GHCi it’s quite intuitive, but less so on a slide. Basically, we have three bind chains, and we just plumb them together using function application. It looks a lot like inlined compose.
fromMonad m = BindK (m >>=)
newtype BindK m a = BindK { }
suspended bind!
Just like before, we’re going to suspend bind in a function by partially applying it. We can lower back into the target monad by directing that bind pipeline into a return. Note that this is the only return in our resulting expression. The expression will be in monadic normal form. I’ll flesh out the types now, but don’t stress. It’s just the right-hand side of a bind. Just like we had a Monoid for AppendK, and a Functor for MapK, we can build a Monad instance for BindK. Wrapping an interface in functions produces a thing that’s slightly more general than that interface. Don’t worry about the monad instance too much either. If you work it out in GHCi it’s quite intuitive, but less so on a slide. Basically, we have three bind chains, and we just plumb them together using function application. It looks a lot like inlined compose.
fromMonad m = BindK (m >>=)
newtype BindK m a = BindK { }
suspended bind!
toMonad (BindK k) = k return
_only_ return!
Just like before, we’re going to suspend bind in a function by partially applying it. We can lower back into the target monad by directing that bind pipeline into a return. Note that this is the only return in our resulting expression. The expression will be in monadic normal form. I’ll flesh out the types now, but don’t stress. It’s just the right-hand side of a bind. Just like we had a Monoid for AppendK, and a Functor for MapK, we can build a Monad instance for BindK. Wrapping an interface in functions produces a thing that’s slightly more general than that interface. Don’t worry about the monad instance too much either. If you work it out in GHCi it’s quite intuitive, but less so on a slide. Basically, we have three bind chains, and we just plumb them together using function application. It looks a lot like inlined compose.
fromMonad m = BindK (m >>=)
newtype BindK m a = BindK { }
suspended bind!
toMonad (BindK k) = k return
_only_ return!
runBindK :: forall b. (a -> m b) -> m b
fromMonad :: Monad m => m a -> BindK m a
toMonad :: Monad m => BindK m a -> m a
Just like before, we’re going to suspend bind in a function by partially applying it. We can lower back into the target monad by directing that bind pipeline into a return. Note that this is the only return in our resulting expression. The expression will be in monadic normal form. I’ll flesh out the types now, but don’t stress. It’s just the right-hand side of a bind. Just like we had a Monoid for AppendK, and a Functor for MapK, we can build a Monad instance for BindK. Wrapping an interface in functions produces a thing that’s slightly more general than that interface. Don’t worry about the monad instance too much either. If you work it out in GHCi it’s quite intuitive, but less so on a slide. Basically, we have three bind chains, and we just plumb them together using function application. It looks a lot like inlined compose.
fromMonad m = BindK (m >>=)
newtype BindK m a = BindK { }
suspended bind!
toMonad (BindK k) = k return
_only_ return!
runBindK :: forall b. (a -> m b) -> m b
fromMonad :: Monad m => m a -> BindK m a
toMonad :: Monad m => BindK m a -> m a
instance Monad (BindK m) where (BindK m) >>= k = BindK (\c -> m (\a -> runBindK (k a) c))
(just plumbing)
Just like before, we’re going to suspend bind in a function by partially applying it. We can lower back into the target monad by directing that bind pipeline into a return. Note that this is the only return in our resulting expression. The expression will be in monadic normal form. I’ll flesh out the types now, but don’t stress. It’s just the right-hand side of a bind. Just like we had a Monoid for AppendK, and a Functor for MapK, we can build a Monad instance for BindK. Wrapping an interface in functions produces a thing that’s slightly more general than that interface. Don’t worry about the monad instance too much either. If you work it out in GHCi it’s quite intuitive, but less so on a slide. Basically, we have three bind chains, and we just plumb them together using function application. It looks a lot like inlined compose.
instance Monad (BindK m) where (BindK m) >>= k = BindK (\c -> m (\a -> runBindK (k a) c))
(just plumbing)
The Functor instance performs fmap fusion, just like MapK! There are no Functor or Monad constraints on BindK’s instances. It’s slightly more general than a Monad transformer.
instance Monad (BindK m) where (BindK m) >>= k = BindK (\c -> m (\a -> runBindK (k a) c))
(just plumbing)
instance Functor (BindK f) where fmap f (BindK m) = BindK (\k -> m (k . f))
The Functor instance performs fmap fusion, just like MapK! There are no Functor or Monad constraints on BindK’s instances. It’s slightly more general than a Monad transformer.
instance Monad (BindK m) where (BindK m) >>= k = BindK (\c -> m (\a -> runBindK (k a) c))
(just plumbing)
instance Functor (BindK f) where fmap f (BindK m) = BindK (\k -> m (k . f)) Same as MapK!
The Functor instance performs fmap fusion, just like MapK! There are no Functor or Monad constraints on BindK’s instances. It’s slightly more general than a Monad transformer.
instance Monad (BindK m) where (BindK m) >>= k = BindK (\c -> m (\a -> runBindK (k a) c))
(just plumbing)
instance Functor (BindK f) where fmap f (BindK m) = BindK (\k -> m (k . f))
Same as MapK!
The Functor instance performs fmap fusion, just like MapK! There are no Functor or Monad constraints on BindK’s instances. It’s slightly more general than a Monad transformer.
We can use BindK to fix both of our benchmarks at once. For the Writer benchmark, by reassociating the binds to the right, we’ve produced a right-associated list append under the hood. We solved it in a different way.
We can use BindK to fix both of our benchmarks at once. For the Writer benchmark, by reassociating the binds to the right, we’ve produced a right-associated list append under the hood. We solved it in a different way.
For our fmap benchmark, all we do is raise into BindK and use its fmap. Same outcome!
For our fmap benchmark, all we do is raise into BindK and use its fmap. Same outcome!
nothing but functions
The implementations of these concepts in Haskell are nothing but functions. The concepts themselves are much more complicated and worthy of study.
nothing but functions
The implementations of these concepts in Haskell are nothing but functions. The concepts themselves are much more complicated and worthy of study.
nothing but functions
The implementations of these concepts in Haskell are nothing but functions. The concepts themselves are much more complicated and worthy of study.
nothing but functions
The implementations of these concepts in Haskell are nothing but functions. The concepts themselves are much more complicated and worthy of study.
nothing but functions
The implementations of these concepts in Haskell are nothing but functions. The concepts themselves are much more complicated and worthy of study.
nothing but functions
The implementations of these concepts in Haskell are nothing but functions. The concepts themselves are much more complicated and worthy of study.
nothing but functions
The implementations of these concepts in Haskell are nothing but functions. The concepts themselves are much more complicated and worthy of study.
Codensity was popularised by Janis Voigtlander’s paper about improving free monads. His improve function would select Codensity (Free f) instead of Free f. It’s since been further improved upon in Free by Ed Kmett’s Church-encoding. More functions!
(all of the above) (… and more)
“mother of all monads”
(because functions)
… but what I really should have called this talk was “ContT a la carte”. ContT is a more powerful version of Codensity, permitting wild and wacky control flow.
(all of the above) (… and more)
“mother of all monads” à la carte
(because functions)
… but what I really should have called this talk was “ContT a la carte”. ContT is a more powerful version of Codensity, permitting wild and wacky control flow.
Like DList, but with special low-level operations.
The “DList trick” is very common in the wild. You probably use ByteString Builders all the time. A Builder is just a newtyped function, and we append them with function composition. The concrete append used under the hood is low-level magic.
Like DList, but with special low-level operations.
Likewise, Lazy Text Builder is just a newtyped function with composition and low-level operations.
Gabriel Gonzalez’s great Foldl library looks a lot like MapK. It is a CPS embedding of left folds, producing fold fusion. This involves building up a fold function using function composition, just like we accumulated mapping functions in MapK. The result: folds make only one pass over the data. Loop fusion!
The master-class for this technique is Eric Mertens’ generic-traverse. (This is just a teaching exercise, not a library.) He uses a stack of CPS-embedded primitives up to Applicative to fuse things together. When used to derive generic functions, the newtypes go away, and the composition chains are in the perfect shape for GHC’s rewrite rules. We end up with derived functions that are as good as hand-written code.
Remorse