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'
, andt = 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.(∀ (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:
(∀ (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
.(∀ (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?
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.
]]>Back when I was writing my PhD thesis on combinatorial species, I was aware that André Joyal’s original papers introducing combinatorial species are written in French, which I don’t read. I figured this was no big deal, since there is plenty of secondary literature on species in English (most notably Bergeron et al., which, though originally written in French, has been translated into English by Margaret Readdy). But at some point I asked a question on MathOverflow to which I hadn’t been able to find an answer, and was told that the answer was already in one of Joyal’s original papers!
So I set out to try to read Joyal’s original papers in French (there are two in particular: Une théorie combinatoire des séries formelles, and Foncteurs analytiques et espèces de structures), and found out that it was actually possible since (a) they are mathematics papers, not high literature; (b) I already understand a lot of the mathematics; and (c) these days, there are many easily accessible digital tools to help with the task of translation.
However, although it was possible for me to read them, it was still hard work, and for someone without my background in combinatorics it would be very tough going—which is a shame since the papers are really very beautiful. So I decided to do something to help make the papers and their ideas more widely accessible. In particular, I’m making an English translation of the papers^{1}—or at least of the first one, for now—interspersed with my own commentary to fill in more background, give additional examples, make connections to computation and type theory, or offer additional perspective. I hope it will be valuable to those in the English-speaking mathematics and computer science communities who want to learn more about species or gain more appreciation for a beautiful piece of mathematical history.
This is a long-term project, and not a high priority at the moment; I plan to work on it slowly but steadily. I’ve only worked on the first paper so far, and I’m at least far enough along that I’m not completely embarrassed to publicize it (but not much more than that). I decided to publicize my effort now, instead of waiting until I’m done, for several reasons: first, it may be a very long time before I’m really “done”, and some people may find it helpful or interesting before it gets to that point. Second, I would welcome collaboration, whether in the form of help with the translation itself, editing or extending the commentary, or simply offering feedback on early drafts or fixing typos. You can find an automatically updated PDF with the latest draft here, and the github repo is here. There are also simple instructions for compiling the paper yourself (using stack) should you want to do that.
And yes, I checked carefully, and this is explicitly allowed by the copyright holder (Elsevier) as long as I put certain notices on the first page.