This problem and its solution has been well-studied in the context of combinatorics; we were wondering what additional insight could be gained from a higher-level functional approach. You can get a preprint here.

]]>`mupf`

joined the `#haskell-ops`

channel yesterday to tell us that Ertugrul Söylemez died unexpectedly on May 12. This is a great loss for the Haskell community. Going variously by `mm_freak`

, `ertes`

, `ertesx`

or `ertes-w`

, Ertugrul has been very active on the `#haskell`

IRC channel for almost 11 years—since June 2007—and he will be remembered as a knowledgeable, generous, and patient teacher. In addition to teaching on IRC, he wrote several tutorials, such as this one on foldr and this one on monoids. The thing Ertugrul was probably most well-known for in the Haskell community was his netwire FRP package, which he had developed since 2011, and more recently its successor package wires. I think it is no exaggeration to say that his work on and insights into FRP helped shape a whole generation of approaches.
He will be greatly missed. I will leave the comments open for anyone to share memories of Ertugrul, his writing, or his code.

]]>The main summer school (July 9–21) has a focus on parallelism and concurrency, but for those with less background, there is also a one-week introduction on the foundations of programming languages (July 3–8). If you want, you can actually choose to attend **only** the July 3–8 session (or both, or just July 9–21 of course). Attending just the introductory session could be a great option for someone who knows some functional programming but wants a more solid grounding in the underlying theory.

If you’re a member of the Haskell/FP community who is thinking of applying, and I’m familiar with you or your work, I would be happy to write you a recommendation if you need one.

]]>At the time, I was reading part of Janis Voigtländer’s habilitation thesis. Unsure where to even start, I decided to just answer straightforwardly: “I’m reading a very long story about free theorems.”

He persisted. “What are free theorems?”

Never one to shrink from a pedagogical challenge, I thought for a moment, then began: “Do you know what a *function* is?” He didn’t. “A function is like a machine where you put something in one end and something comes out the other end. For example, maybe you put a number in, and the number that is one bigger comes out. So if you put in three, four comes out, or if you put in six, seven comes out.” This clearly made sense to him, so I continued, “The *type* of a function machine tells you what kinds of things you put in and what kinds of things come out. So maybe you put a number in and get a number out. Or maybe you put in a *list* of numbers and get a number out.” He interrupted excitedly, “Or maybe you could put *words* in??” “Yes, exactly! Maybe you can put words in and get words out. Or maybe there is a function machine where you put *other function machines* in and get function machines out!” He gasped in astonishment at the idea of putting function machines into function machines.

“So,” I concluded, “a free theorem is when you can say something that is always true about a function machine if you *only* know its type, but you *don’t* know anything about what it does on the inside.” This seemed a bit beyond him (and to be fair, free theorems are only interesting when polymorphism is involved which I definitely didn’t want to go into). But the whole conversation had given me a different idea.

“Hey, I have a good idea for a game,” I said. “It’s called the function machine game. I will think of a function machine. You tell me things to put into the function machine, and I will tell you what comes out. Then you have to guess what the function machine does.” He immediately liked this game and it has been a huge hit; he wants to play it all the time. We played it while driving to a party yesterday, and we played it this morning while I was in the shower. So far, he has correctly guessed:

I tried but that was a bit tough for him. I realized that in some cases he may understand intuitively what the function does but have trouble expressing it in words (this was also a problem with ), so we started using the obvious variant where once the guesser thinks they know what the function does, the players switch roles and the person who came up with function specifies some inputs in order to test whether the guesser is able to produce the correct outputs.

was also surprisingly difficult for him to guess (though he did get it right eventually). I think he was just stuck on the idea of the function doing something arithmetical to the input, and was having trouble coming up with some sort of arithmetic procedure which would result in no matter what you put in! It simply hadn’t occurred to him that the machine might *not care* about the input. (Interestingly, many students in my functional programming class this semester were also confused by constant functions when we were learning about the lambda calculus; they really wanted to substitute the input *somewhere* and were upset/confused by the fact that the bound variable did not occur in the body at all!)

After a few rounds of guessing my functions, he wanted to come up with his own functions for me to guess (as I knew he would). Sometimes his functions are great and sometimes they don’t make sense (usually because his idea of what the function does changes over time, which of course he, in all sincerity, denies), but it’s fun either way. And after he finally understood , he came up with his own function which was something like

inspired, I think, by his kindergarten class where they were learning about pairs of numbers that added up to .

Definitely one of my better parenting days.

]]>Please consider submitting something! As in previous years, we are accepting a wide range of types of submissions. Paper and demo submissions are due by June 28: you can submit original research, a technology tutorial, a call for collaboration, or propose some sort of live demo. In addition, we also solicit performances to be given during the associated performance evening—performance proposals are due by July 8.

See the website for more info, and let me know if you have any questions!

]]>`Bifunctor`

, `Bifoldable`

, and `Bitraversable`

to the Typeclassopedia. While thinking and writing about `Bifunctor`

I ended up proving some “folklore” results for my own satisfaction, and decided someone might possibly find it useful if I formally record the proofs here.
The `Bifunctor`

type class governs types of kind `* -> * -> *`

which are (covariantly) functorial in both type arguments; that is, we can map over the two type arguments independently:

```
class Bifunctor (p :: * -> * -> *) where
bimap :: (a -> b) -> (c -> d) -> p a c -> p b d
first :: (a -> b) -> p a c -> p b c
second :: (b -> c) -> p a b -> p a c
```

`bimap`

allows mapping over both type arguments simultaneously, for example, `bimap toUpper (+1) ('j', 3) = ('J',4)`

. `first`

and `second`

allow mapping over only one or the other. Note that `bimap`

can be implemented in terms of `first`

and `second`

, or `first`

and `second`

in terms of `bimap`

(we’ll see what these implementations are later, or you can work them out as an easy exercise if you haven’t seen them before).

Instances of `Bifunctor`

should satisfy some laws, which are straightforward analogues of the laws for `Functor`

instances:

```
bimap id id = id (IB)
bimap (f . g) (h . i) = bimap f h . bimap g i (CB)
first id = id (IF)
first (f . g) = first f . first g (CF)
second id = id (IS)
second (f . g) = second f . second g (CS)
```

So far so good. But there is an additional law relating `bimap`

, `first`

, and `second`

:

`bimap f g = first f . second g (BFS)`

When I first read this law, it gave me pause: unlike the other laws, there seems to be some arbitrary asymmetry here. What about the symmetric law BFS2?

`bimap f g = second g . first f (BFS2)`

Intuitively, the order in which we perform `first f`

and `second g`

should not make any difference, since they cannot interact with each other in any way; the `a`

values and `b`

values in an arbitrary `p a b`

structure have to be distinct. That is, intuitively, if (BFS) holds, then (BFS2) should hold as well, and I wondered whether it is possible to formally derive this fact.

Let us note first that if one defines a `Bifunctor`

instance by defining `bimap`

alone, then `first`

and `second`

receive default definitions:

```
first f = bimap f id
second g = bimap id g
```

In this case, assuming that `bimap`

satisfies its composition law (CB), we can see that

```
first f . second g
= bimap f id . bimap id g
= bimap (f . id) (id . g)
= bimap f g
= bimap (id . f) (g . id)
= bimap id g . bimap f id
= second g . first f
```

So when `bimap`

alone is defined and satisfies (CB), both (BFS) and (BFS2) hold automatically. Let’s now consider the situation where `first`

and `second`

are defined, and `bimap`

acquires its default definition of `bimap f g = first f . second g`

(which is just (BFS))—or we can assume that all three of `first`

, `second`

, and `bimap`

are defined, as long as law (BFS) still holds. In this case, can we derive (BFS2) as well?

We can derive parametricity, aka a free theorem, for any function with the type of `bimap`

. Let `p :: * -> * -> *`

be some two-argument type. In order to even express parametricity for types involving `p`

, we have to assume that `p`

is functorial—that is, we assume the existence of a function

`BIMAP :: (a -> b) -> (c -> d) -> p a c -> p b d`

satisfying (IB). (As with `Functor`

, (IB) + parametricity is enough to imply that it must satisfy (CB) as well.) We write `BIMAP`

in all caps to indicate that it is some canonical, Platonic function, handed down from on high, inherent to the very essence of `p`

. (Something like that.) Now let us suppose that we mortals have written some function `bimap`

with the same type as `BIMAP`

, which also satisfies (IB). But we don’t make any assumptions about whether our `bimap`

is the same function as `BIMAP`

; we only assume that it has type `(a -> b) -> (c -> d) -> p a c -> p b d`

and satisfies (IB).

We can now take the polymorphic type of `bimap`

and turn the crank to derive a statement of parametricity. I’m assuming some familiarity with this process; for details, see Wadler’s paper. If you don’t care about the details of the derivation, you can just skip to the final statement of parametricity at the end of this section, and then proceed to see how it is applied in the next.

Parametricity for `bimap`

says that if we interpret its type as a relation (according to certain rules), then `(bimap, bimap)`

will be a member of the relation, that is, `bimap`

will be related to itself. Below I show the process of expanding out the definition of the relation corresponding to `bimap`

’s type. (I don’t want to take the time to typeset it really nicely using LaTeX or anything like that; a slightly cleaned-up text version will do for now.) I use `@a`

to denote explicit type application, but after the second step I leave type application implicit to reduce clutter.

```
(bimap,bimap) ∈ ∀ a b c d. (a -> b) -> (c -> d) -> p a c -> p b d
<=>
∀ Q :: a <-> a', R :: b <-> b', S :: c <-> c', T :: d <-> d'.
(bimap @a @b @c @d, bimap @a' @b' @c' @d')
∈ (Q -> R) -> (S -> T) -> p Q S -> p R T
<=>
∀ Q :: a <-> a', R :: b <-> b', S :: c <-> c', T :: d <-> d'.
∀ (g,g') ∈ (Q -> R).
∀ (h,h') ∈ (S -> T).
∀ (x,x') ∈ p Q S.
(bimap g h x, bimap g' h' x') ∈ p R T
<=>
∀ Q :: a <-> a', R :: b <-> b', S :: c <-> c', T :: d <-> d'.
∀ (g,g'). (∀ (y,y') ∈ Q. (g y, g' y') ∈ R) ->
∀ (h,h'). (∀ (z,z') ∈ S. (h z, h' z') ∈ T) ->
∀ (x,x') ∈ p Q S.
(bimap g h x, bimap g' h' x') ∈ p R T
```

At this point, we don’t need the extra generality afforded by assuming everything is a *relation*, so we specialize all the relations in sight to functions. For example, the relation `Q :: a <-> a'`

just becomes a function `q :: a -> a'`

; statements of relatedness, such as `(y,y') ∈ Q`

, turn into equations like `q y = y'`

.

```
∀ q :: a -> a', r :: b -> b', s :: c -> c', t :: d -> d'.
∀ (g,g'). (∀ (y,y'). q y = y' -> r (g y) = g' y') ->
∀ (h,h'). (∀ (z,z'). s z = z' -> t (h z) = h' z') ->
∀ (x,x') ∈ p q s.
(bimap g h x, bimap g' h' x') ∈ p r t
```

We now have to interpret `p q s`

and `p r t`

as relations. Wadler’s original paper doesn’t really cover this; it only talks about the specific case of the list functor. However, reading between the lines (and consulting subsequent work on parametricity), we can see that the right way to do this is

`(a,b) ∈ p f g <=> BIMAP f g a = b`

That is, we interpret the type `p`

as the relation corresponding to its `BIMAP`

function. Hence, we now have

```
∀ q :: a -> a', r :: b -> b', s :: c -> c', t :: d -> d'.
∀ (g,g'). (∀ (y,y'). q y = y' -> r (g y) = g' y') ->
∀ (h,h'). (∀ (z,z'). s z = z' -> t (h z) = h' z') ->
∀ (x,x'). (BIMAP q s x = x') ->
BIMAP r t (bimap g h x) = bimap g' h' x'
```

Finally, we can simplify this by substituting equals for equals in a few places:

```
∀ q :: a -> a', r :: b -> b', s :: c -> c', t :: d -> d'.
∀ (g,g'). (∀ (y,y'). r (g y) = g' (q y)) ->
∀ (h,h'). (∀ (z,z'). t (h z) = h' (s z)) ->
∀ (x,x').
BIMAP r t (bimap g h x) = bimap g' h' (BIMAP q s x) (PAR)
```

This is the specific statement of parametricity for `bimap`

that we will use to derive the results below.

`bimap`

Let’s first prove that `bimap`

is unique—that is, anything with the type of `bimap`

must in fact be equal to `BIMAP`

. The name of the game is just to pick appropriate values for all those quantified variables in (PAR). In particular, let’s pick

`g = h = q = s = id`

,`r = g'`

, and`t = h'`

.

We have some conditions to check:

`(∀ (y,y'). r (g y) = g' (q y))`

under our choices becomes`(∀ (y,y'). r (id y) = r (id y))`

which is obviously true.- Likewise,
`(∀ (z,z'). t (h z) = h' (s z))`

becomes`(∀ (z,z'). t (id z) = t (id z))`

which is also obviously true.

We then get to conclude that `∀ (x,x'). BIMAP r t (bimap g h x) = bimap g' h' (BIMAP q s x)`

, which is equivalent to

```
∀ (x,x'). BIMAP r t (bimap g h x) = bimap g' h' (BIMAP q s x)
<=>
BIMAP r t . bimap g h = bimap g' h' . BIMAP q s
<=>
BIMAP r t . bimap id id = bimap r t . BIMAP id id
```

Since we have assumed that both `BIMAP`

and `bimap`

satisfy the `id`

law, this is equivalent to `BIMAP r t = bimap r t`

, so `bimap`

and `BIMAP`

coincide (`r`

and `t`

were arbitrary).

`first`

and `second`

commuteFinally, let’s prove that `first`

and `second`

commute. We will again use (PAR), but with different choices:

`g = g' = t = s = id`

`h = h'`

`q = r`

Let’s check the conditions:

- We have to check
`(∀ (y,y'). r (g y) = g' (q y))`

, which becomes`(∀ (y,y'). r (id y) = id (r y))`

, which is true since both sides reduce to`r y`

. - Likewise,
`(∀ (z,z'). t (h z) = h' (s z))`

becomes`(∀ (z,z'). id (h z) = h (id z))`

which is true by similar reasoning.

Hence, we may conclude that `BIMAP r t (bimap g h x) = bimap g' h' (BIMAP q s x)`

, which is equivalent to

`BIMAP r id . bimap id h = bimap id h . BIMAP r id`

We can simplify this further using a few assumptions: first, we already showed that `BIMAP = bimap`

. Second, since we are assuming (BFS), that is, `bimap f g = first f . second g`

, setting `f`

or `g`

to `id`

shows that `bimap f id = first f . second id = first f . id = first f`

(by the `id`

law for `second`

), and likewise `bimap id g = second g`

. Hence the equation becomes

`first r . second h = second h . first r`

And voila!

One can also show that the `id`

laws plus parametricity together imply the composition laws—I will leave that as an exercise. (Hint: make appropriate choices for `g'`

, `h'`

, `q`

, and `s`

.)

*On a certain input, an algorithm runs in one-tenth of a second. On the same input, an algorithm takes one and a half weeks to run. Approximately how long would an algorithm take on the same input?*

*a few seconds?**a few minutes?**a few hours?**a few days?*

I’m pretty sure it wasn’t until quite a few years out of undergrad that I would have gotten this right.

]]>The initial application deadline is soon (February 28)—I forgot to post something about it earlier!—but we’ll continue to accept applications until the position is filled, so don’t hesitate to apply even if you end up missing the deadline by a bit. And of course feel free to contact me with any questions.

]]>