First let's define substitution in the linear lambda calculus the way we'd do normally, then try to introduce some more general machinery.
Just as in the last post, we'll start by defining relevant covers, well-scoped lambda terms, and substitutions
data Cover : (k, l, m : List a) -> Type where
Done : Cover [] [] []
Left : Cover k l m -> Cover (a :: k) l (a :: m)
Right : Cover k l m -> Cover k (a::l) (a :: m)
Both : Cover k l m -> Cover (a :: k) (a::l) (a :: m)
-- Binary operators like 'App' have a Cover wrapped around them
data Term : List String -> Type where
Var : {s : String} -> Term [s]
Lam : {s : String} -> Term (s::g) -> Term g
App : Cover g1 g2 g -> Term g1 -> Term g2 -> Term g
data Sub : List String -> List String -> Type where
Nil : Sub [] []
-- ^the empty substitution
Cons : {a : String} -> Term g1 -> Cover g1 g2 g -> Sub g2 d -> Sub g (a::d)
-- add a term in context g1 to a substitution with context g2,
-- and append their contextsBut now, let's actually see what the guts of substitution look like.
TODO: Substitution in plan
TODO: cleaned up substitution
Now, what happens if we factor out the cover outside of Sub? This means that, what if instead of combining each individual context using Sub, we collect them into a list of contexts, and only have one outer cover?
]]>For very subtle theoretical reasons, the core language that we're developing needs to be substructural. The problem isn't with copying/deleting by itself - we can still copy and delete variables - this just needs to be done explicitly, at least in the core language. Jules wrote about representing explicitly cartesian languages on this blog before.
So the current intention is that the concrete syntax will be cartesian as normal, but it will desugar to a substructural core language with explicit copy and delete, aka. the Co-de-Bruijn representation. (Though now that we're working on a substructural core, we've actually been talking about experimenting with the design space of languages like Rust).
The problem we're facing, however, is that it's entirely unclear how to adapt a correct-by-construction implementation of a polymorphic language to a substructural discipline.
So the purpose of this blog series is two-fold:
On one hand, I would like to document the current progress of our language implementation in Idris - this will both be a showcase of using dependent types for general compiler engineering, as well as a collection of various folklore around implementing substructural languages specifically.
On the other hand, there are still many open questions that we have in this space, and there are practically no publications on this topic. So we would like to solicit feedback and see if anyone has some ideas that we've overlooked.
In this blog post I will introduce the problem by defining two separate lambda calculi - one with substructural variables, and one with polymorphism. The question of how to combine the two will be one of the main things that we'd like to answer by the time the series finishes.
Let's start with the simply-typed substructural lambda calculus.
The main thing that happens when switching from a cartesian to a
linear syntax is that we can no longer implicitly share contexts. This
means that variables become singletons - only one thing can be in scope
at the leaves, and that each term has its own context, so rules that
involve more than one term (such as App) now need to
explicitly combine them.
-- Naive representation of linear terms
data Term : List String -> Type where
Var : {s : String} -> Term [s]
Lam : {s : String} -> Term (s::g) -> Term g
App : Term g1 -> Term g2 -> Term (g1 ++ g2)This of course creates the dreaded green slime in the domain of
App - we now have a function in our data-type definition,
which will cause problems later.
Because of this, the standard solution is to use 'covers', which represent the function (++) as a proof-relevant relation. This gives us a way to pattern-match on the Cover when needed, thus avoiding the unifier from getting stuck in such cases.
-- A relation for splitting relevant terms.
-- Each variable either goes into one of the contexts, or both.
data Cover : (k, l, m : List a) -> Type where
Done : Cover [] [] []
Left : Cover k l m -> Cover (a :: k) l (a :: m)
Right : Cover k l m -> Cover k (a::l) (a :: m)
Both : Cover k l m -> Cover (a :: k) (a::l) (a :: m)Given a context m, the cover shows how to decompose it
into the contexts k and l, by putting each
variable into either one or both of the contexts.
Our term representation now looks like this.
-- Binary operators like 'App' have a Cover wrapped around them
data Term : List String -> Type where
Var : {s : String} -> Term [s]
Lam : {s : String} -> Term (s::g) -> Term g
App : Cover g1 g2 g -> Term g1 -> Term g2 -> Term gThis won't be a full introduction to Co-de-Bruijn, for more details I recommend this blog post by Jesper Cockx (Ctrl+F for 'Co-de-Bruijn'), Conor's original paper, or this great Masters thesis by Matthias Heinzel.
In this blog post I'd like to focus on one of the reasons for why we care about Co-de-Bruijn, which is that it eliminates one of the biggest sources of inefficiency when it comes to implemeting substitution.
Regardless of which representation of substitution we use, we will inevitably need to perform substitution under binders. Traditionally, this is done by introducing the concept of a renaming, or thinning. The idea is that as we substitute under binders we additionally perform a renaming of a term, extending its context with a new variable. András Kovacs has a great reference implementation here.
Semantically, this is nice - renaming forms a functor, substitution forms a (relative) monad on that functor. (We will look at this semantic perspective in more detail in a future series, but for now we'll just focus on the syntax).
Operationally, this is a nightmare - we now need to traverse each term twice, and moreover, the renaming doesn't do anything beyond keeping the contexts of sub-terms in sync with each other. Context sharing was meant to be a simplification, but now it induces a major operational cost on our implementation.
The beautiful thing about substructural languages is that they forego the need for renaming - because contexts are split, there's no need to keep them in sync. And because the variables are now singletons, there is no need to traverse the entire term just to update its context about all the variables it won't be using anyway.
In practice, our substitution datatype would look like this.
-- A substitution for a substructural language
data Sub : List String -> List String -> Type where
Nil : Sub [] []
-- ^the empty substitution
Cons : {a : String} -> Term g1 -> Cover g1 g2 g -> Sub g2 d -> Sub g (a::d)
-- add a term in context g1 to a substitution with context g2,
-- and append their contexts
-- Substitution traverses the term and applies the environment to each subterm
subst : Term g -> Sub d g -> Term d(Compare it to this definition in Kovac's implementation which uses implcit context-sharing). The only difference is that whenever we Cons a new term on the environment, we need to explicitly add its context using a cover.
This works well, modulo some wrangling of covers, for which we've come up with some helpful combinators with the help of Vikraman Choudhury, and that I'll show in the next blog post.
For now, the main point is that the most expensive operation - extending the context by a new variable - is now entirely free, rather than requiring us to individually weaken each term in the environment.
ext : {g' : List Ty} -> Sub g g' -> Sub (s :: g) (s :: g')
ext lift e = Cons Var (Left coverRightId) eAll we do is Cons a variable to an existing environment
e, and our cover is a proof that the new variable goes on
the left-most context, while all the other variables go on the right
(this is what coverRightId does). None of the actual terms
in e are touched at any point.
Now, unfortunately... I don't think this substitution datatype generalises to the polymorphic case, at least not in an obvious way.
To see that, let's first sketch out what a polymorphic language with shared contexts looks like.
András Kovacs has us covered once again, as he has a great reference implementation.
Unlike András, we will be going with a well scoped rather than well typed representation, in order to avoid the buckets of green slime that a typical intrinsically typed implementation of System F will saddle us with.
First we will define types, which are now indexed by a list of type variables.
data Ty : (typeVars : List String) -> Type where
VarT : Elem a g -> Ty g
-- ^ Type variables
Forall : Ty (s::g) -> Ty g
-- ^ Type quantification
Mu : Ty (s::g) -> Ty g
-- ^ Least fixpoint of a datatype
(~>) : Ty g -> Ty g -> Ty g
-- ^ Function typeFor terms contexts, the simplest approach is to define them as being indexed by two independent lists, one for type variables and one for term variables, as is done by Sandro Stucki here:
Term : (typeVars : List String) -> (termVars : List String) -> TypeThis representation is convenient to work with, but misses an important connection between the two contexts - term variables can refer to type variables in their types! So a more informative representation would allow the term context to be synced with the type context, and the standard solution to this is to index the latter by the former.
-- a list indexed by another list
data IxList : (a : Type) -> List a -> Type where
Nil : IxList a []
-- ^the empty IxList is indexed by the empty List
(::) : a -> IxList a ls -> IxList a ls
-- ^add a new term variable without touching the index
(:::) : (el : a) -> IxList a as -> IxList a (el::as)
-- ^add a new type variable,
-- increasing the type context by which future term variables will be indexedWe now need a version of the Elem
data-type for indexed list, ie. a proof-relevant variable that keeps
track of its position in the context.
data IxElem : a -> IxList a ks -> Type where
Here : IxElem a (a :: as)
There : IxElem a as -> IxElem a (b :: as)
ThereK : IxElem a as -> IxElem a (b ::: as)We've now got everything to define a well scoped fragment of System F.
data Term : (tyVars : List String)
-> (trmVars : IxList String tyVars) -> Type where
Var : (var : String) -> IxElem {tyVars} var termVars -> Term tyVars termVars
-- Proof that the variable var is in the IxList termvars
Lam : (a : String) -> (tya : Ty tyVars)
-> Term tyVars (a :: trmVars) -> Term tyVars trmVars
-- Lambda abstraction is standard, and includes a type annotation `ty`
App : Term tyVars trmVars -> Term tyVars trmVars
-> Term tyVars trmVars
-- lambda application is standard
In : (f : Ty (tyVar :: tyVars)) -> Term tyVars trmVars -> Term tyVars trmVars
-- inject into a term of a recursive type `f`
Out : (f : Ty (tyVar :: tyVars)) -> Term tyVars trmVars -> Term tyVars trmVars
-- project from a term of a recursive type `f`
TLam : (tyVar : String) -> Term (tyVar :: tyVars) (tyVar ::: trmVars)
-> Term tyVars trmVars
-- type abstraction now binds a type variable `k` in both contexts
TApp : Term tyVars trmVars -> Ty tyVars -> Term tyVars trmVars
-- Type application applies a type to a term with a type lambdaFor now we will assume some familiarity with System F, so I won't go into too much detail into what each constructor does, but we can rectify that in a future blog post. I recommend this paper by Chapman et al (aptly called "System F in Agda, for Fun and Profit") in the meantime.
At this point, we have enough to start defining renaming and substitution, but before that we should take note of something interesting: because we designed our term contexts to be indexed by type contexts, this decision will propagate across all context operations. So term renamings are indexed by type renamings, and term substitutions are indexed by type substitutions.
For our purposes, we only care about substitution, since a substructural type system side-steps renaming.
In order to define term substitutions we first need to define type substitutions:
-- type substitution with implicitly shared contexts 'g'
data TySub : List String -> List String -> Type where
NilTy : TySub g []
-- ^empty type substitution.
ConsTy : (tyVar : String) -> Ty g -> TySub g d -> TySub g (tyVar::d)
-- ^extend the type substitution with a new variableContrast this to the earlier implementation of Sub which
used a cover to concatenate contexts - we are now assuming that the
context g is the same across all terms. While this
simplifies the datatype, it comes at the cost of requiring any operation
on term contexts (such as weakening) to apply to all terms in
the substitution.
We can see this once we define substitution, which is no different to substitution in any well scoped syntax.
-- projection from the environment
indexEnv : TySub g d -> Elem a d -> Ty g
indexEnv (ConsTy a x y) Here = x
indexEnv (ConsTy a x y) (There t) = indexEnv y t
-- Traverse a type and substitute all the type variables
tySubst : TySub g d -> Ty d -> Ty g
tySubst sub (VarT x) = indexEnv sub x
tySubst sub (Forall s x) = Forall s $ tySubst (tyExt sub) x
tySubst sub (Mu s x) = Mu s $ tySubst (tyExt sub) x
tySubst sub (Imp x y) = Imp (tySubst sub x) (tySubst sub y)
-- extending the type environment
extTy : TySub g d -> TySub (s :: g) (s :: d)Just as before, we rely on the extension operation tyExt
when dealing with binders such as Forall or Mu. This operation weakens
the context of each value in the substitution, thus requiring a full
traversal of each value. Unlike with the substructural case, where we
get this operation for free, defining it here requires us to also define
renaming, and so we'll elide this definition for now (but it can be
found in any of the reference implementations above).
What we're really interested in is term substitutions, so lets see what our new datatype looks like.
data TrmSub : (g : IxList String as) -> (sub : TySub as bs)
-> (d : IxList String bs) -> Type where
NilTrm : TrmSub g NilTy []
-- an empty term substitution indexed by an empty type substitution
ConsTrm : (trmVar : String) -> Term tyVars g
-> TrmSub g sub d -> TrmSub g sub (trmVar::d)
-- extend the term variable context by `trmVar` without affecting the type variables
ConsTrmTy : (tyVar : String) -> (ty : Ty tyVars)
-> TrmSub g sub d -> TrmSub g (ConsTy tyVar ty sub) (tyVar ::: d)
-- extend both the term and type variable contexts by a type variable `tyVar`This is... a lot, so let's break it down into components.
The first thing we notice is that the type of TrmSub is indexed by an
instance of TySub - ie. in order to map a term context g,
which is indexed by a type context as, into d,
which is indexed by bs, we need to explain how to map
as to bs. (Jules tells me that this means that
we're probably dealing with a fibration).
The rules for NilTrm and ConsTrm are just as before, except that
NilTrm is indexed by the empty type substitution, and ConsTrm is indexed
by an arbitrary type substitution sub, which it does not
interact with.
The interesting case is ConsTrmTy - it extends the term
substitution by a type variable - which in turn means that it
needs to extend the indexing type substitution sub with the
same variable.
We can now define the action of substitution on terms, and just like with term contexts and term substitutions it will be indexed by a corresponding action of type substitutions on types. Unlike before, I'll work through the full definition here:
-- Lookup a term in an environment
lookupTrm : TrmSub d tySub g -> IxElem as g -> Term bs d
lookupTrm (ConsTrm a x y) Here = x
lookupTrm (ConsTrm b y z) (There x) = indexTrmEnv z x
lookupTrm (ConsTrmTy b y z) (ThereK x) = indexTrmEnv z x
-- Substitute a term
trmSubst : (tySub : TySub as bs) -> (trmSub : TrmSub g tySub d)
-> Term bs d -> Term as g
trmSubst tySub trmSub (Var a x)
= lookupTerm trmSub x
trmSubst tySub trmSub (Lam a tya x)
= Lam a (tySubst tySub tya) (trmSubst tySub (extTrm trmSub) x)
trmSubst tySub trmSub (App x y)
= App (trmSubst tySub trmSub x) (trmSubst tySub trmSub y)
trmSubst tySub trmSub (In ty trm)
= In (tySubst (extTy tySub) ty) (trmSubst tySub trmSub trm)
trmSubst tySub trmSub (Out ty trm)
= Out (tySubst (extTy tySub) ty) (trmSubst tySub trmSub trm)
trmSubst tySub trmSub (TLam k trm)
= TLam k $ trmSubst (extTy tySub) (extTrmTy trmSub) trm
trmSubst tySub trmSub (TApp trm ty)
= TApp (trmSubst tySub trmSub trm) (tySubst tySub ty)Let's work through these one by one.
Var is unchanged beyond looking up the value in a more
complicated environment.
Lam extends the term substitution just as in the simply
typed case, but now performs an additional type substitution on its type
annotation.
App is the same as with the STLC.
Both In and Out involve a binder in the
datatype that we're taking the fixpoint over, so they require us to
perform an extension of the type substitution, but they substitute the
term itself as normal.
TLam is the most interesting case because it binds a
type variable inside a term. This means that we need to extend the type
substitution, as well as extend the term substitution by a new
type variable. This is the reason why TrmSub has
the shape it does.
TApp is not much more complicated than App,
except that one of the things it substitutes is a term and the other is
the type that we're applying to it.
Of note is the fact that term substitutions now have two extension operations:
-- extend the term substitution by a new term variable
extTrm : TrmSub g tySub d -> TrmSub (a :: g) tySub (a :: d)
-- extend the term substitution by a new *type* variable
extTrmTy : TrmSub g tySub d -> TrmSub (k ::: g) (extTy tySub) (k ::: d)extTrm leaves the type substitution alone, but
extTrmTy extends both the term substitution and the type
substitution that it's indexed by with the same variable
And just as before, in order to implement extTrm and
extTrmTy we would need to implement term renamings which
are indexed by type renamings. This is standard, and is included in all
of the earlier references.
At this point we have two generalisations of the simply typed lambda calculus - one takes us into substructural types, the other into polymorphism. It would be really nice if we could combine the two, and define a substructural polymorphic language. Unfortunately though, it's extremely not obvious how to do this.
The usual answer provided in the literature is to keep the type contexts cartesian, and only make the term contexts linear. After all, what does it even mean for a type context to be linear?
While this works on paper, this would make the implementation quite cumbersome. What makes the implementation above as slick as it is, is the fact that the inductive structure of type-indexed-terms closely matches the inductive structure of the types indexing them. Letting types have implicitly shared contexts while enforcing a linear discipline on terms would not work so well (or at all?). And moreover, if one of the reasons for working substructurally is to avoid the expensive renaming operation, it would be a job-half-done if we eliminated term renamings while keeping renamings of types.
So while it's true that it doesn't quite make sense to talk about "linear type contexts", we could still talk about 'explicitly cartesian contexts', ie. Co-de-Bruijn-style contexts which allow copying and deleting of type variables so long as that's done explicitly, rather than implicitly through context-sharing.
But this still begs the question - what should the right definition of a polymorphic substructural lambda calculus even be?
Defining polymorphic covers would not be such a big deal - working by analogy with the other polymorphic operations, we can guess that a cover that handles term contexts will be indexed by a cover for type contexts.
But where things break down is when we need to define linear term substitutions, ie. this data-type:
data LinTrmSub : (g : IxList String as) -> (sub : LinTySub as bs)
-> (d : IxList String bs) -> Type whereI have attempted this a few times now, but each time I reached a dead-end.
Jules suspects that this is because monoidal fibrations are much less obvious to work with than cartesian fibrations, but I have not figured out how to translate the extra data needed in the definition of a monoidal fibration into code.
So this is the problem that we're currently facing, and I'd be interested if anyone has some ideas here.
In the meantime, the blog series will explore the things that we do know how to do well. In the next few posts I'll show you how to work with covers more generally, how to define scope-checkers and type-checkers for substructural languages, and how to put all the pieces together into a full compiler pipeline using Andre Videla's library for dependent compiler pipelines.
]]>In this post I'll explain how to build well-typed by construction implementations of substructural languages, that is, languages in which our ability to delete, copy and/or swap variables in scope is restricted. I will begin by recounting the folklore that I learned from Conor Mc Bride and Zanzi, and then I will explain a useful trick that I invented: terms that are parametrised by an action of a category of context morphisms.
Personally, my main interest in this topic comes from my plans to implement a bidirectional programming language in which all programs are optics, so they can be run in both a forwards mode and a backwards mode. Due to the subtle categorical structure of optics, such a programming language is substructural in a very unique and complicated way. I have found in practice that actions of context morphisms help a lot to make this problem tractable. I'll be continuing to document my development of this language on the CyberCat Institute blog.
We begin with a tiny language for types, with monoidal products (a neutral name because later we will be making it behave like different kinds of product), a unit type to be the neutral element of the monoidal product, and a "ground" type that is intended to contain some nontrivial values.
data Ty : Type where
Unit : Ty
Ground : Ty
Tensor : Ty -> Ty -> TyAlthough we have used the name "tensor", suppose we want to make an ordinary cartesian language where variables can be implicitly copied and discarded. Here is a standard way to do it: it is an intuitionistic natural deduction calculus.
data Term : List Ty -> Ty -> Type where
-- A variable is a term if we can point to it in scope
Var : Elem x xs -> Term xs x
-- Unit is always a term in every scope
UnitIntro : Term xs Unit
-- Pattern matching on Unit, redunant here but kept for comparison to later
UnitElim : Term xs Unit -> Term xs x -> Term xs x
-- A pair is a term if each side is a term
TensorIntro : Term xs x -> Term xs y -> Term xs (Tensor x y)
-- Pattern matching on a pair, adding both sides to the scope
TensorElim : Term xs (Tensor x y) -> Term (x :: y :: xs) z -> Term xs zThe constructor for Var uses Elem, a
standard library type that defines pointers into a list:
data Elem : a -> List a -> Type where
Here : Elem x (x :: xs)
There : Elem x xs -> Elem x (x' :: xs)Here are some examples of programs we can write in this language:
-- \x => ()
delete : CartesianTerm [a] Unit
delete = UnitIntro
-- \(x, y) => x
prjl : CartesianTerm [a, b] a
prjl = Var Here
-- \(x, y) => y
prjr : CartesianTerm [a, b] b
prjr = Var (There Here)
-- \x => (x, x)
copy : CartesianTerm [a] (Tensor a a)
copy = TensorIntro (Var Here) (Var Here)
-- \(x, y) => (y, x)
swap : CartesianTerm [a, b] (Tensor b a)
swap = TensorIntro (Var (There Here)) (Var Here)The thing that makes this language cartesian and allows us to write
these 3 terms is the way that the context xs gets shared by
the inputs of the different term constructors. In the next section we
will define terms a different way, and then none of these examples will
typecheck.
Next let's go to the opposite extreme and build a fully substructural language, in which we cannot delete or copy or swap. I learned how to do this from Conor Mc Bride and Zanzi. Here is the idea:
data Term : List Ty -> Ty -> Type where
-- A variable is a term only if it is the only thing in scope
Var : Term [x] x
-- Unit is a term only in the empty scope
UnitIntro : Term [] Unit
-- Pattern matching on Unit consumes its scope
UnitElim : Term xs Unit -> Term ys y -> Term (xs ++ ys) y
-- Constructing a pair consumes the scopes of both sides
TensorIntro : Term xs x -> Term ys y -> Term (xs ++ ys) (Tensor x y)
-- Pattern matching on a pair consumes its scope
TensorElim : Term xs (Tensor x y) -> Term (x :: y :: ys) z -> Term (xs ++ ys) zThis is a semantically correct definition of planar terms and it
would work if we had a sufficiently smart typechecker, but for the
current generation of dependent typecheckers we can't use this
definition because it suffers from what's called green slime.
The problem is that we have types containing terms that involve the
recursive function ++, and the typechecker will get stuck
when this function tries to pattern match on a free variable. (I have no
idea how you learn this if you don't happen to drink in the same pubs as
Conor. Dependently typed programming has a catastrophic lack of books
that teach it.)
The fix is that we need to define a datatype that witnesses that the
concatenation of two lists is equal to a third list - a witness that the
composition of two things is equal to a third thing is called a
simplex. The key idea is that this datatype exactly reflects
the recursive structure of ++, but as a relation rather
than a function:
data Simplex : List a -> List a -> List a -> Type where
Right : Simplex [] ys ys
Left : Simplex xs ys zs -> Simplex (x :: xs) ys (x :: zs)Now we can write a definition of planar terms that we can work with:
data Term : List Ty -> Ty -> Type where
Var : Term [x] x
UnitIntro : Term [] Unit
UnitElim : Simplex xs ys zs
-> Term xs Unit -> Term ys y -> Term zs y
TensorIntro : Simplex xs ys zs
-> Term xs x -> Term ys y -> Term zs (Tensor x y)
TensorElim : Simplex xs ys zs
-> Term xs (Tensor x y) -> Term (x :: y :: ys) z -> Term zs zThis language is so restricted that it's hard to show it doing anything, but here is one example of a term we can write:
-- \(x, y) => (x, y)
foo : Term [a, b] (Tensor a b)
foo = TensorIntro (Left Right) Var VarManually defining simplicies, which cut a context into two halves, is very good as a learning exercise but eventually gets irritating. We can direct Idris to search for the simplex automatically:
data Term : List Ty -> Ty -> Type where
Var : Term [x] x
UnitIntro : Term [] Unit
UnitElim : {auto prf : Simplex xs ys zs}
-> Term xs Unit -> Term ys y -> Term zs y
TensorIntro : {auto prf : Simplex xs ys zs}
-> Term xs x -> Term ys y -> Term zs (Tensor x y)
TensorElim : {auto prf : Simplex xs ys zs}
-> Term xs (Tensor x y) -> Term (x :: y :: ys) z -> Term zs z
foo : Term [a, b] (Tensor a b)
foo = TensorIntro Var VarThis works, but I find that the proof search gets confused easily (although it works fine for the baby examples in this post), so let's pull out the big guns and write a tactic:
concat : (xs, ys : List a) -> (zs : List a ** Simplex xs ys zs)
concat [] ys = (ys ** Right)
concat (x :: xs) ys = let (zs ** s) = concat xs ys in (x :: zs ** Left s)This function takes two lists and returns their concatenation
together with a simplex that witnesses this fact. Here **
is Idris syntax for both the type former and term former for dependent
pair (aka. Sigma) types.
data Term : List Ty -> Ty -> Type where
Var : Term [x] x
UnitIntro : Term [] Unit
UnitElim : {xs, ys : List Ty}
-> {default (concat xs ys) prf : (zs : List Ty ** Simplex xs ys zs)}
-> Term xs Unit -> Term ys y -> Term prf.fst y
TensorIntro : {xs, ys : List Ty}
-> {default (concat xs ys) prf : (zs : List Ty ** Simplex xs ys zs)}
-> Term xs x -> Term ys y -> Term prf.fst (Tensor x y)
TensorElim : {xs, ys : List Ty}
-> {default (concat xs ys) prf : (zs : List Ty ** Simplex xs ys zs)}
-> Term xs (Tensor x y) -> Term (x :: y :: ys) z -> Term prf.fst z
foo : {a, b : Ty} -> Term [a, b] (Tensor a b)
foo = TensorIntro Var VarI find Idris' default syntax to be a bit awkward, but it
feels to me like a potentially very powerful tool, and something I wish
Haskell had for scripting instance search.
Unfortunately, going from a planar language to a linear one - that is, ruling out copy and delete but allowing swaps - is much harder. I figured out a technique for doing this that turns out to be very powerful and give very fine control over the scoping rules of a language.
The idea is to isolate a category of context morphisms (technically a
coloured pro, that is a
strict monoidal category whose monoid of objects is free). Then we will
parametrise a planar language by an action of this category. The good
news is that this is the final iteration of the definition of
Term, and we'll be working with it for the rest of this
blog post.
Structure : Type -> Type
Structure a = List a -> List a -> Type
data Term : Structure Ty -> List Ty -> Ty -> Type where
Var : Term hom [x] x
Act : hom xs ys -> Term hom ys x -> Term hom xs x
UnitIntro : Term hom [] Unit
UnitElim : {xs, ys : List Ty}
-> {default (concat xs ys) prf : (zs : List Ty ** Simplex xs ys zs)}
-> Term hom xs Unit -> Term hom ys y -> Term hom prf.fst y
TensorIntro : {xs, ys : List Ty}
-> {default (concat xs ys) prf : (zs : List Ty ** Simplex xs ys zs)}
-> Term hom xs x -> Term hom ys y -> Term hom prf.fst (Tensor x y)
TensorElim : {xs, ys : List Ty}
-> {default (concat xs ys) prf : (zs : List Ty ** Simplex xs ys zs)}
-> Term hom xs (Tensor x y) -> Term hom (x :: y :: ys) z
-> Term hom prf.fst zFirst, let's recover planar terms. To do this, we want to define a
Structure where hom xs ys is a proof that
xs = ys:
data Planar : Structure a where
Empty : Planar [] []
Whisker : Planar xs ys -> Planar (x :: xs) (x :: ys)Now let's deal with linear terms. For that, we want to define a
Structure where hom xs ys is a proof that
ys is a permutation of xs. We can do this in
two steps:
-- Insertion x xs ys is a witness that ys consists of xs with x inserted somewhere
data Insertion : a -> List a -> List a -> Type where
-- The insertion is at the head of the list
Here : Insertion x xs (x :: xs)
-- The insertion is somewhere in the tail of the list
There : Insertion x xs ys -> Insertion x (y :: xs) (y :: ys)
data Symmetric : Structure a where
-- The empty list has a unique permutation to itself
Empty : Symmetric [] []
-- Extend a permutation by inserting the head element into the permuted tail
Insert : Insertion x ys zs -> Symmetric xs ys -> Symmetric (x :: xs) zs(Incidentally, this is the point where I realised that although Idris looks like Haskell, programming in it feels a lot closer to programming in Prolog.)
Now we write swap as term:
swap : {a, b : Ty} -> Term Symmetric [a, b] (Tensor b a)
swap = Act (Insert (There Here) (Insert Here Empty)) (TensorIntro Var Var)Now we can come full circle and redefine cartesian terms in a way that uniformly matches the way we do substructural terms.
data Cartesian : Structure a where
-- Delete everything in scope
Delete : Cartesian xs []
-- Point to a variable in scope and make a copy on top
Copy : Elem y xs -> Cartesian xs ys -> Cartesian xs (y :: ys)With this, we can rewrite all the terms we started with:
delete : {a : Ty} -> Term Cartesian [a] Unit
delete = Act Delete UnitIntro
prjl : {a, b : Ty} -> Term Cartesian [a, b] a
prjl = Act (Copy Here Delete) Var
prjr : {a, b : Ty} -> Term Cartesian [a, b] b
prjr = Act (Copy (There Here) Delete) Var
copy : {a : Ty} -> Term Cartesian [a] (Tensor a a)
copy = Act (Copy Here (Copy Here Delete)) (TensorIntro Var Var)
swap : {a, b : Ty} -> Term Cartesian [a, b] (Tensor b a)
swap = Act (Copy (There Here) (Copy Here Delete)) (TensorIntro Var Var)Let's end with a party trick. What would a cocartesian language look like - one where we can't delete or copy, but we can spawn and merge?
Co : Structure a -> Structure a
Co hom xs ys = hom ys xs
-- spawn : Void -> a
-- spawn = \case {}
spawn : {a : Ty} -> Term (Co Cartesian) [] a
spawn = Act Delete Var
-- merge : Either a a -> a
-- merge = \case {Left x => x; Right x => x}
merge : {a : Ty} -> Term (Co Cartesian) [a, a] a
merge = Act (Copy Here (Copy Here Delete)) Var
-- injl : a -> Either a b
-- injl = \x => Left x
injl : {a, b : Ty} -> Term (Co Cartesian) [a] (Tensor a b)
injl = Act (Copy Here Delete) (TensorIntro Var Var)
-- injr : b -> Either a b
-- injr = \y => Right y
injr : {a, b : Ty} -> Term (Co Cartesian) [b] (Tensor a b)
injr = Act (Copy (There Here) Delete) (TensorIntro Var Var)Since at the very beginning we added a single generating type
Ground, and the category generated by one object and finite
coproducts is finite sets and functions, this language can define
exactly the functions between finite sets. For example, there are
exactly 4 functions from booleans to booleans:
id, false, true, not : Term (Co Cartesian) [Ground, Ground] (Tensor Ground Ground)
id = Act (Copy Here (Copy (There Here) Delete)) (TensorIntro Var Var)
false = Act (Copy Here (Copy Here Delete)) (TensorIntro Var Var)
true = Act (Copy (There Here) (Copy (There Here) Delete)) (TensorIntro Var Var)
not = Act (Copy (There Here) (Copy Here Delete)) (TensorIntro Var Var)That's enough for today, but next time I will continue using this style of term language to start dealing with the difficult issues of building a programming language for optics.
]]>In the previous two blog posts we've looked at a combinator language for categories, as well as a data type for simply typed lambda terms. We've also had a look at translating from one to the other. Both blog posts assumed quite a bit of background knowledge, so our goal today will be to start at the very beginning and introduce recursion schemes step by step.
To start, let's look at how we'd normally implement a datatype for semirings, along with an evaluator for it, and then see how we can generalise it using recursion schemes.
First, we'll add a constructor for each operation.
namespace Simple
data Semiring : Type -> Type where
Val : value -> Semiring value
One : Semiring value
Zero : Semiring value
Mult : Semiring value -> Semiring value -> Semiring value
Add : Semiring value -> Semiring value -> Semiring valueNow we would like to implement an evaluator for each of the constructors of the semiring.
Following the Haskell tradition of writing folds, it would look something like this:
eval : (add : a -> a -> a) -> (mult : a -> a -> a)
-> (zero : a) -> (one : a) -> Semiring a -> a
eval _ _ _ _ (Val v) = v
eval _ _ _ one One = one
eval _ _ zero _ Zero = zero
eval add mult zero one (Mult x y) =
mult (eval add mult zero one x) (eval add mult zero one y)
eval add mult zero one (Add x y) =
add (eval add mult zero one x) (eval add mult zero one y)This function, known as a fold, is capable of expressing any interpreter that consumes this data type. However, while folds are interesting theoretically, the function itself is fairly boilerplate - all it's doing is matching constructors of the datatype to individual functions that consume them.
Since we're going to be writing a lot of datatypes, we want to avoid writing an individual evaluator for each of them - we'd rather get them for free. If we had macros in our language, we could use them for this. But we don't need macros where we're going, as we've got category theory.
The starting idea is that the same way that we bundle up our constructors into a single datatype, we can bundle up our consumers together as well.
record SemiringAlgebra (a : Type) where
add : a -> a -> a
mult : a -> a -> a
zero : a
one : a
-- if we uncurry we can see that these are all just morphisms of a category
record SemiringAlgebra' (a : Type) where
add : (a, a) -> a
mult : (a, a) -> a
zero : () -> a
one : () -> aUsing SemiringAlgebra we can get a slightly cleaner looking evaluator:
eval' : SemiringAlgebra a -> Semiring a -> aBut it would involve the same amount of boilerplate as before.
The problem is that we are essentially declaring each concept twice - once as a constructor, and once as a function consuming it. What we would like is to do declare it once, and derive the rest from that single declaration.
Now, Semiring has the type Type -> Type, and so does
SemiringAlgebra. So we want something of the type
(Type -> Type) -> (Type -> Type). This turns out
to be fairly straightforward:
Algebra : (Type -> Type) -> (Type -> Type)
Algebra f a = f a -> a
SemiringAlgebra' : Type -> Type
SemiringAlgebra' a = Algebra Semiring aBut how would we use such a thing? Naively, it seems that our evaluator has now become trivial:
evalNope : Algebra Semiring a -> Semiring a -> a
evalNope alg s = alg sThis type checks, however it does not do anything interesting, it merely applies the function that we've supplied to it, and we still need to define that function manually. What we really want is for this function to be derived for us from smaller pieces.
To resolve this, we notice that our original SemiringAlgebra record does not actually tell us how to tear down a full semiring. All it does is tell us how to tear down each individual layer. So let's start by describing these layers as a data type.
data SemiringLayer : Type -> Type -> Type where
Val : value -> SemiringLayer value expression
One : SemiringLayer value expression
Zero : SemiringLayer value expression
Mult : expression -> expression -> SemiringLayer value expression
Add : expression -> expression -> SemiringLayer value expressionThe structure of this datatype is very similar to our original
Semiring. But whereas Semiring was inductive - we defined complex
expressions in terms of simpler ones - our new SemiringLayer only
defines the contents of a single layer. And rather than being
parametrised by a single type of values Type -> Type, we
now take two parameters Type -> Type -> Type: one for
values, and one for complex expressions.
The result is that our ideal evaluator would now look like this:
evalAlg : Algebra (SemiringLayer val) val -> Algebra Semiring valIn other words, we lift an algebra over a layer of a semiring to an
algebra over the entire semiring. The final piece of the puzzle is that
we would like to derive Semiring from
SemiringLayer, rather than defining them separately.
We do this by using a type-level fixpoint that operates on datatypes.
data Fix : (layer : Type -> Type) -> Type where
In : {layer : Type -> Type} -> layer (Fix layer) -> Fix layerIt is not unlike a standard fixpoint operator that works on functions:
partial
fix : (a -> a) -> a
fix f = f (fix f)
-- Don't try this at home:
-- SemiringBoom : Type -> Type
-- SemiringBoom value = fix (SemiringLayer value)Using Fix, we can now define Semiring
inductively in terms of SemiringLayer - each time that
SemiringLayer expects an expression, Fix will
fill that in with Fix SemiringLayer as a subexpression:
Semiring : Type -> Type
Semiring value = Fix (SemiringLayer value)
-- example expression
ex1 : Semiring Nat
ex1 = In (Mult (In One) (In $ Val 2))The small downside is that we now have In around our
code, however this can be avoided using smart constructors.
Now we can finally define our evaluator uniformly without mentioning any individual constructor:
-- We'll need a functor constraint for what's to come:
Functor (SemiringLayer a) where
map f (Val x) = Val x
map f One = One
map f Zero = Zero
map f (Mult x y) = Mult (f x) (f y)
map f (Add x y) = Add (f x) (f y)
-- Lift an algebra of a semiring layer to a semiring
eval : Algebra (SemiringLayer val) a -> Fix (SemiringLayer val) -> a
eval alg (In op) = alg (map (eval alg) op)And since our eval makes no reference to the
constructors of Semiring, this means that we can generalise
it to an arbitrary functor.
-- Mission accomplished.
cata : Functor f => Algebra f a -> Fix f -> a
cata alg (In op) = alg (map (cata alg) op)We can now apply our cata to arbitrary datatypes (with
some restrictions, that we will talk about later in the blog), and
provided that we give them a functor constraint.
data ListLayer : Type -> Type -> Type where
Nil : ListLayer val expr
Cons : val -> expr -> ListLayer val expr
Functor (ListLayer a) where
map f [] = []
map f (Cons x y) = Cons x (f y)
List : Type -> Type
List a = Fix (ListLayer a)
-- we get the evaluator for free!
foldr : Algebra (ListLayer a) a -> Fix (ListLayer a) -> a
foldr = cataIt's worth tracing out what exactly happens when we use
eval - the gist of it is that there are two things that we
need to do: use map to go under an f to turn
f (Fix f) into f a, and then use
alg to turn an f a into a.
We can split cata into two mutually-inductive functions,
each of which is responsible for one of these steps. As a bonus, this
makes it structurally recursive over Fix f.
mutual
-- take a layer of `f a` to an `a`
fold : Functor f => (f a -> a) -> Fix f -> a
fold alg (In x) = alg (mapFold alg x)
-- go underneath an f to turn Fix f to a
mapFold : Functor f => (f a -> a) -> f (Fix f) -> f a
mapFold alg op = map (fold alg) opIt can get tedious writing all these functor constraints after a while. If we had macros, we could automate this, but once again we can get away without macros with the help of category theory - using what is known as the Coyoneda trick.
A lot has been written about the Yoneda lemma, and its dual cousin, Coyoneda. Personally, I find that it's one of those concepts that you don't so much "understand" as "get used to". And the best way to get used to something is to use it, which - luckily for us - we'll have plenty of opportunity to do.
The datatype representing Coyoneda is simple, it is a pair of a value inside of a functor, and a function that will map this value. Essentially, it is nothing more than a suspended map operation:
data Coyoneda : (Type -> Type) -> Type -> Type where
Map : {0 a : _} -> (a -> b) -> f a -> Coyoneda f b
-- map : (a -> b) -> f a -> f bIn other words, Coyoneda is to functors as SemiringLayer is to semirings - it's a data type that holds the contents of a functorial map, the same way that SemiringLayer holds values of some semiring. Like SemiringLayer, Coyoneda comes with its own notion of algebra, and we will make this precise in a futre blog post.
-- When `f` is a functor, we can tear down a layer of Coyoneda
mapCoyo : Functor f => Coyoneda f b -> f b
mapCoyo (Map f fa) = map f faUsing this trick, we can modify our generic evaluator to no longer need a functor constraint:
mcata : Algebra (Coyoneda f) c -> Fix f -> c
mcata alg (In op) = alg (Map (mcata alg) op)The m in mcata stands for
Mendler, and Algebra (Coyoneda f) a is
commonly known as a Mendler Algebra.
MAlgebra : (Type -> Type) -> (Type -> Type)
MAlgebra f a = Algebra (Coyoneda f) aKmett wrote a great
post about catamorphisms and Mendler catamorphisms, and it includes
how to go from cata to mcata and vice
versa.
The downside of using Mendler-style recursion schemes is that our algebras become a tad more involved. Compare the following:
-- monoid of natural numbers, standard algebra style
algPlus : Algebra (ListLayer Nat) Nat
algPlus [] = 0
algPlus (Cons x y) = x + y
-- monoid of natural numbers, Mendler style
malgPlus : MAlgebra (ListLayer Nat) Nat
malgPlus (Map f []) = 0
malgPlus (Map f (Cons x y)) = x + f yWhereas a normal algebra merely accesses the values of each constructor, a Mendler algebra carries around an extra function that we need to apply before accessing sub-expressions.
One way around this is to use algebra transformers, ie. a way to turn a simple algebra into a more complex one. In this case, we can derive a Mendler algebra from a standard one:
malgToAlg : Algebra (ListLayer v) a -> MAlgebra (ListLayer v) a
malgToAlg alg (Map f []) = alg []
malgToAlg alg (Map f (Cons x y)) = alg (Cons x (f y))We can now use standard algebras with mcata, as if they
were Mendler algebras:
listEval' : Algebra (ListLayer v) a -> Fix (ListLayer v) -> a
listEval' alg = mcata (malgToAlg alg)What's interesting is that if we look at malgToAlg
closely, we'll see that it's nothing other than an inside out functor
interface for ListLayer. So in the end we did about the same amount of
work as before, but at least with Mendler algebras we could choose when
to do it, and we were not forced to write all of our interfaces up
front.
If we had macros at our disposal, we could actually derive malgToAlg automatically. And... well, now I actually wish that I had macros at my disposal here. (Or at least that I had a working knowledge of elaborator reflection, which could accomplish the same thing).
At this point, we might wonder if going through Mendler algebras is worth it if they are equally expressive to standard algebras. As we will soon see, the answer is yes, as a small generalisation to Mendler algebras - leading to what I call "Kan algebras" - will give us a vast amount of expressive power that can capture many datatypes of interest besides those representable as functors on sets.
But before we get to that, let us talk about monads.
]]>In the previous post we've defined a typed combinator language for bicartesian closed categories. In this post, we will define the Simply Typed Lambda Calculus and translate it into our combinator language.
The reason why we'd want to do this is that while combinators allow us to work with the primitives of some categorical structure, they make for a very austere programming language - one with no variables or binding. So while it's possible to program entirely in combinators, we would be limiting ourselves to writing point-free programs. Instead, we will write our programs in the STLC and compile the code into combinators.
But while the translation from lambda terms to closed cartesian categories is standard, there is a slight impedance mismatch between variable contexts and products that we will encounter again and again. So in addition to showing the translation itself, the goal of this blog post is to start introducing the idea of categories with a first-class notion of context, aka multicategories.
Just as before, we start by defining a type for our STLC types, as well as infix type synonyms for each type constructor.
data Ty : Type where
Unit : Ty
Prod : Ty -> Ty -> Ty
Sum : Ty -> Ty -> Ty
Exp : Ty -> Ty -> Ty
N : Ty
infixr 5 ~>
(~>) : Ty -> Ty -> Ty
(~>) = Exp
infixr 5 :*:
(:*:) : Ty -> Ty -> Ty
(:*:) = Prod
infixr 5 :+:
(:+:) : Ty -> Ty -> Ty
(:+:) = SumAs we can see, the types stay the same as before. In fact, looking at the STLC and our combinator language side by side reveals that a lot of structure is carried over with little modification.
Let's start by looking at the core language, and then add the rest of the constructors.
-- Terms of the Simply Typed Lambda Calculus
data Term : List Ty -> Ty -> Type where
-- Variables
Var : {g : List Ty} -> {a : Ty} -> Elem a g -> Term g a
-- Primitives
Prim : {g : List Ty} -> {a : Ty} -> Prims g a -> Term g a
-- Lambda abstraction
Lam : {g : List Ty} -> {a, b : Ty} -> Term (a::g) b -> Term g (a ~> b)
-- Lambda application
App : {g : List Ty} -> {a, b : Ty} -> Term g (a ~> b) -> Term g a -> Term g bThe first thing we notice is that our type signature has changed.
While combinators take a single input to a single output
Ty -> Ty -> Type, we are now working with a list of
inputs - aka our variable context - which is then taken to an output
List Ty -> Ty -> Type. Since we will use the latter
type a lot, we'll define a type synonym for it, and call it a
multigraph.
Graph : Type -> Type
Graph obj = obj -> obj -> Type
Multigraph : Type -> Type
Multigraph obj = List obj -> obj -> TypeSince we now have a list of inputs as opposed to a single input, we
need some way of embedding variables into our variable context. This is
done using the Var constructor. It kind of looks like the
identity arrow from the combinator language if you squint, and indeed
the correspondence would become a lot more precise if we were working
with a linear lambda calculus:
Id : {a : Ty} -> Comb _ a a
LVar : {a : Ty} -> Term [a] a
Var : {a : Ty} -> {g : List Ty} -> Elem a g -> Term g aSo Id takes a single input to a single output,
Var embeds a variable into a larger context, while
LVar embeds the variable into a singleton context. From
this we can see the difference between linear and cartesian variables -
cartesian variables can be projected out of a larger context, ignoring
the rest, while linear variables must be used without anything else
remaining.
Here Elem
is taken from the Idris standard library, it's kind of proof-relevant
membership relation, which guarantees that the variable a
will be inside of the larger context g.
data Elem : a -> List a -> Type where
||| A proof that the element is at the head of the list
Here : Elem x (x :: xs)
||| A proof that the element is in the tail of the list
There : Elem x xs -> Elem x (y :: xs)
-- Find the variable corresponding to Elem t g, from an environment Env g
lookup : Elem t g -> Env g -> evalTy t
lookup Here (x ::- xs) = x
lookup (There t) (y ::- xs) = lookup t xsWe can also see that lambda abstraction looks kind of like currying, but flipped. If we were to work with Snoc-lists instead of Cons-lists then we would see the correspondence between the two constructors a lot clearer:
-- Snoc List
data SList a = Lin | Snoc (SList a) a
infixr 5 -:
(-:) : SList a -> a -> SList a
(-:) = Snoc
Lam : {g : SList Ty} -> Term (g -: a) b -> Term g (a ~> b)
Curry : {c : Ty} -> Comb _ (c :*: a) b -> Comb _ c (a ~> b)We can see that the two line-up very closely, except that Curry takes
as an input a morphism from a tuple (c :*: a), while Lam
takes as an input a term with the context g -: a. Lambda
abstraction then takes the free variable a, and binds it
inside the function (a ~> b). So in a way, a context is
just a convenient representation for an n-ary tuple.
Unfortunately, while the Snoc-list representation makes working with lambda abstraction much easier, it will complicate working with the rest of our binding operators, so we will not be using it in the full language.
We've also split Apply into multiple terms. Whereas previously the entire operation was expressed as a single combinator, we are now defining it as a meta-operation on terms, each with their own context:
App : Term g (a ~> b) -> Term g a -> Term g b
Apply : Comb _ ((a ~> b) :*: a) bThis will be a recurring pattern in the translation, and many other combinators will be split this way.
We can also see that just as we've changed the type of our term
language to be a multigraph, we've done the same to our primitives
Prims : List Ty -> Ty -> Type. Similar to Lam, each
primitive will take a number of variables from the context and bind them
to a primitive expression.
Let's define some primitives. Just like before, we'd like to work with the generators of a monoid. There are a few choices of representation that we can take here, depending on how we want our primitives to interact with the context.
The easiest thing to do would be to say that our generators take a
number of variables from some larger context, and leave the rest of the
context unchanged, implicitly discarding it. The unit of the monoid
takes no variables from the context g, and leaves the
entire thing unchanged, while the multiplication takes two variables
N :: N :: g, and leaves the rest.
-- Primitives with "cartesian" contexts
data CPrims : Multigraph Ty where
CZ : CPrims g N
CMult : CPrims (N :: N :: g) NThis would be convenient to program with, since we could embed our primitives inside terms with an arbitrary context.
ex : {g : List Ty} -> Term g (N ~> (N ~> N))
ex = Lam (Lam (Prim CMult))Unfortunately - as we will see below - this would make the translation to combinators a lot more cumbersome. So instead, we will use primitives with a more careful context discipline, only admitting contexts with the exact number of variables that will be used.
So the monoid unit will require an empty context [],
which is equivalent to a morphism from the unit object, and the monoid
multiplication will use a context with exactly two free variables, which
is equivalent to a morphism from a tuple. This will make the translation
to the set of primitives from the last post almost trivial. Almost.
-- Primitives with "linear" contexts
data LinPrims : Multigraph Ty where
LZ : LinPrims [] N
LMult : LinPrims [N, N] N
-- the context needs to be empty, or the expression won't type-check
ex' : {g : List Ty} -> Term Nil (N ~> (N ~> N))
ex' = Lam (Lam (Prim LMult))Alternatively, we could have defined our set of primitives within the language itself:
data STLC : List Ty -> Ty -> Type where
-- ... stlc constructors
E : STLC g N
Mult : STLC g N -> STLC g N -> STLC g NBut this would not maintain the clean separation between the primitives and the terms built on top of them, like we did in our combinator language.
Our presentation also gives us an insight into a more subtle relationship between lambda terms and combinators - combinators are defined over an underlying graph, while terms are defined over an underlying multigraph.
Having looked at the core language, let's now turn our attention to the full language:
data Term : Multigraph Ty where
-- Variables
Var : {g : List Ty} -> {a : Ty} -> Elem a g -> Term g a
-- Primitives
LPrim : {g : List Ty} -> {a : Ty} -> LPrims g a -> Term g a
-- Lambda abstraction: (a::g → b) → (g → (a ⇨ b))
Lam : {g : List Ty} -> {a, b : Ty} -> Term (a::g) b -> Term g (a ~> b)
-- Lambda application: (g → (a ~> b)) → (g → a) → (g → a)
App : {g : List Ty} -> {a, b : Ty} ->
Term g (a ~> b) -> Term g a -> Term g b
-- First projection: (g → (a * b)) → (g → a)
Fst : {g : List Ty} -> {a, b : Ty} -> Term g (Prod a b) -> Term g a
-- Second projection: (g → (a * b)) → (g → b)
Snd : {g : List Ty} -> {a, b : Ty} -> Term g (Prod a b) -> Term g b
-- Product introduction: (g → a) → (g → b) → (g → (a * b))
Pair : {g : List Ty} -> {a, b : Ty}
-> Term g a -> Term g b -> Term g (Prod a b)
-- Left injection: (g → a) → (g → a + b)
InL : {g : List Ty} -> {a, b : Ty} -> Term g a -> Term g (Sum a b)
-- Right injection: (g → b) → (g → a + b)
InR : {g : List Ty} -> {a, b : Ty} -> Term g b -> Term g (Sum a b)
-- Case matching: (g → a + b) → (a::g → c) → (b::g → c) → (g → c)
Case : {g : List Ty} -> {a, b, c : Ty} ->
Term g (Sum a b) -> Term (a::g) c -> Term (b::g) c -> Term g c
-- Let binding: (g → s) → (s::g → t) → (g → t)
Let : {g : List Ty} -> {s : Ty}
-> Term g s -> Term (s::g) t -> Term g tWe can see that just as with the core language, the new connectives fall into two categories - they either interact with the context, such as Case and Let, or they do not.
Let is often seen as redundant since it can be defined
using Lam, but doing so is only valid in a category with
exponentials. While this is obviously true in our full language, our
goal is to mix-and-match the syntax as needed. So keeping the Let
operator will allow us to retain the ability to bind variables even if
we move to a subset of the language without lambda abstraction.
In fact, if we look closely at the Let connective, we'll notice that it's possible to work in a language with nothing but variables and Let.
Let : Term g s -> Term (s :: g) t -> Term g t
(flip Comp) : Comb _ c s -> Comb _ s t -> Comb _ c tSo Let is nothing other than composition! Or to be more
precise, it's a notion of composition for morphisms that contain
variable contexts. We will call these 'multi-morphisms'. Meanwhile, the
constructor for linear variables LVar that we've seen
earlier is a notion of an identity arrow for multi-morphisms.
Taking this a step further, we can see a correspondence between a free category on a graph, and a free "multicategory" on a multigraph.
-- Free category over a graph 'g'.
data Cat : {obj : Type} -> Graph obj -> Graph obj where
Id : {a : obj} -> Cat g a a
Cons : {a, b, c : obj} -> g b c -> Cat g a b -> Cat g a c
-- Free multicategory over the multigraph 'm'.
data Multicat : {obj : Type} -> Multigraph obj -> Multigraph obj where
LVar : {a : obj} -> Multicat m [a] a
Let : {ctx : List obj} -> {s, t : obj} ->
m ctx s -> Multicat m (s :: ctx) t -> Multicat m ctx t(Strictly speaking, this is a cartesian multicategory, since the context 'ctx' is shared between terms).
But this is getting ahead of ourselves. We will talk about multicategories - including non-cartesian ones - in much more detail later, but for now let's get back to the lambda calculus.
Having defined our term language, let's start by translating it into Idris' types and functions, after which we will do a more general translation into combinators.
As always, we start by translating the types. This stays exactly as in our last post:
evalTy : Ty -> Type
evalTy Unit = Unit
evalTy N = Nat
evalTy (Exp t1 t2) = (evalTy t1) -> (evalTy t2)
evalTy (Prod t1 t2) = (evalTy t1, evalTy t2)
evalTy (Sum t1 t2) = Either (evalTy t1) (evalTy t2)Next we would like to translate the primitives, however here we face our first complication. Previously our evaluator converted a primitive into a function from one input to one output:
evalPrims : Prims ty1 ty2 -> Idr (evalTy ty1) (evalTy ty2)Now we would like to define a function from multiple inputs to an output:
evalPrims : Prims g ty -> (Idr (?evalCtx g) (evalTy t))How should we represent these multi-input functions? We can think of n-ary functions as functions out of an environment, represented as a heterogeneous list of values.
We will use the following representation of our environment. We can
think of it as a list of values (evalTy t) indexed by our
context List Ty.
-- Cons list, extends environment from the left
infixr 5 ::-
data Env : List Ty -> Type where
CNil : Env Nil
(::-) : evalTy t -> Env g -> Env (t :: g)Contrast it to the definition of a list:
data List : Type -> Type
Nil : List a
Cons : t -> List t -> List tWe can think of an environment as a kind of "heterogenous list of values indexed by a list of types of those values".
We will instantiate our monoid as the monoid of natural numbers
Nat. Then our evaluator for primitives becomes as follows.
The monoidal unit does not interact with the environment, creating a 0
out of nothing. The monoidal multiplication pops two natural numbers
from the environment and adds them.
evalPrims : LPrims g t -> Idr (Env g) (evalTy t)
evalPrims E CNil = 0
evalPrims Mult (m1 ::- m2 ::- CNil) = m1 + m2Combining the above, we get our evaluator that takes terms to n-ary Idris functions. If you compare it to our BCC evaluator from before, then not a lot changes - the constructors that don't interact with the context remain almost the same. The constructors that do interact with the environment - Lam, Case, Let - all involve extending the environment with a new variable, which then gets bound and used within the expression.
eval : {g : List Ty} -> Term g t -> Idr (Env g) (evalTy t)
eval (Var v) env = lookup v env
eval (LPrim e) env = evalPrims e env
eval (Lam t) env = \x => eval t (x ::- env)
eval (App t1 t2) env = (eval t1 env) (eval t2 env)
eval (Pair t1 t2) env = (eval t1 env, eval t2 env)
eval (Fst t) env = fst (eval t env)
eval (Snd t) env = snd (eval t env)
eval (Let t c) env = eval c ((eval t env) ::- env)
eval (InL t) env = Left (eval t env)
eval (InR t) env = Right (eval t env)
eval (Case t1 t2 t3) env = case eval t1 env of
Left l => eval t2 (l ::- env)
Right r => eval t3 (r ::- env)Finally, we would like to translate our lambda calculus into bicartesian closed categories. Generalising from Idris functions, our goal looks something like
eval : (bcc : BCC g) -> Term g ty -> bcc (Env g) (evalTy t)However, our environment Env is defined for Idris types, so we would need to generalise it. So what we'll do is interpret our context of types into a product of types, with the empty list being represented by the Unit type.
At first glance, we might want to simply fold over our context:
ctxF : List Ty -> Ty
ctxF tys = foldr Prod Unit tysHowever, this would create awkward-looking types such as
(Prod a (Prod b) Unit). So a more nicer alternative would
be to convert the empty List into Unit, but not use that as a base case,
and instead treat the embedding [a] of a type into a list
as the base case instead. This would give us nicer-looking types without
trailing units at the end.
ctxEv : List Ty -> Ty
ctxEv Nil = Unit
ctxEv [t] = t
ctxEv (t::ts) = Prod t (ctxEv ts)Using this evaluator, our translation between primitives would be trivial.
-- Translating from LPrims to Typed.Prims
evalPrim : {g : List Ty} -> LPrims g t -> Prims (ctxEv g) t
evalPrim LZ = Typed.Z
evalPrim LMult = Typed.MultUnfortunately, using this much nicer evaluator would complicate type unification immensely, and make the translation much harder to write. So we will use the messier fold instead and just put up with trailing units.
This means that while the monoidal unit translates correctly to
Prims Unit N, the monoidal multiplication becomes
Prims (Pair N (Pair N Unit)) N. We could fix this by using
the structural rules of the combinator language to rearrange the
expression and drop the trailing Unit, but this means that we need to
first embed our primitives into the combinator language, rather than
translating between two sets of primitives directly.
First, let's add some new structural rules to the combinator language.
-- Syntactic sugar for composing arrows:
(>>>) : {a, b, c : Ty} -> Comb k a b -> Comb k b c -> Comb k a c
(>>>) f g = Comp g f
-- | New Combinators
-- Bifunctor for products
BifP : {a, b, c, d : Ty} ->
Comb k a c -> Comb k b d -> Comb k (a :*: b) (c :*: d)
-- Unit elimination
UnitL : {a : Ty} -> Comb g (a :*: Unit) aNow we can do the translation:
-- Won't work without embedding into Comb
evalPrim : {g : List Ty} -> LPrims g t -> Prims (ctxF g) t
evalPrim LZ = Typed.Z
evalPrim LMult = ?sadness
-- Works
evalPrimF : {ctx : List Ty} -> LPrims ctx t -> Comb Prims (ctxF ctx) t
evalPrimF LZ = Prim Typed.Z
evalPrimF LMult = BifP Id UnitL >>> Prim Typed.MultHad we chosen to work with cartesian contexts instead, we would have
needed to deal with the trailing context of unused variables. The
monoidal unit would be Prims (ctxF g) N, with
multiplication Prims (Pair N (Pair N (ctxF g))). This would
mean that for each primitive we'd have to zoom into the nested tuple and
drop the remaining context by composing it with the terminal morphism:
Terminal : {a : Ty} -> Comb k a Unit.
-- Works, but messy
evalPrim' : {ctx : List Ty} -> CPrims ctx t -> Comb Prims (ctxF ctx) t
evalPrim' CZ = Terminal >>> Prim Typed.Z
evalPrim' CMult = BifP Id Fst >>> Prim Typed.MultIn addition to translating the primitives, we also want to translate variables. When working with contexts, a variable is an index into an environment, pointing at a specific value. When working with tuples, a variable is translated into a sequence of projections from a nested tuple.
var : {g : Graph Ty} -> {ctx : List Ty} -> {ty : Ty} ->
Elem ty ctx -> Comb g (ctxF ctx) ty
var Here = Fst
var (There t) = Comp (var t) SndWe're either taking the left-most component with Fst, or traversing the nested tuple with a sequence of Snd's.
Finally, we get our evaluator from terms to combinators. Just like
earlier, the only constructors that require special care are the ones
that interact with the context. Usually these involve some manner of
re-arrangement of nested tuples using the structural rules of
bicartesian closed categories. For instance, had we used Snoc-lists, the
evaluator for Lam would be trivial, but instead we will
re-arrange the context a bit to make it work.
First, we'll go back to our combinator language and add a few more structural combinators to make it work.
-- | New Combinators
-- Distributivity of sums over products
Distrib : {a, b, c : Ty} -> Comb k ((a :+: b) :*: c) ((a :*: c) :+: (b :*: c))
-- Bifunctor for sums
BifC : {a, b, c, d : Ty} ->
Comb k a c -> Comb k b d -> Comb k (a :+: b) (c :+: d)
-- Symmetry for products
SwapP : {a, b : Ty} -> Comb k (a :*: b) (b :*: a)
-- Symmetry for sums
SwapC : {a, b : Ty} -> Comb k (a :+: b) (b :+: a)
-- Unit elimination
UnitL : {a : Ty} -> Comb g (a :*: Unit) a
-- Copy: (a → a * a)
Copy : {a : Ty} -> Comb g a (a :*: a)
-- Cocopy: (a + a → a)
Cocopy : {a : Ty} -> Comb b (a :+: a) aNow we can do the translation itself. The most involved case is that of case matching, which I had Jules help me with. We have a morphism from the context into a sum, as well as two morphisms out of a product of a variable and the context. We need to combine them to get a morphism out of the context.
m1 : g -> a + b
m2 : (a * g) -> ty
m3 : (b * g) -> ty
----------------------
g -> tyAs an Idris expression, it would look like this:
match : (g -> Either a b) -> ((a, g) -> t) -> ((b, g) -> t) -> g -> t
match m1 m2 m3 g = case m1 g of
Left a => m2 (a, g)
Right b => m3 (b, g)Translating this into combinators, we will need the following sequence of transformations:
-- g -> (g * g) -> ((a + b) * g) ~= ((a * g) + (b * g)) -> ty + ty -> ty
sem (Case t1 t2 t3) = Copy >>> BifP (sem t1) Id >>>
Distrib >>> BifC (sem t2) (sem t3) >>> CocopyPutting it all together, our compiler to combinators becomes the following:
-- Translation into combinators
sem : {ctx : List Ty} -> {ty : Ty} -> Term ctx ty -> Comb Prims (ctxF ctx) ty
sem (Var v) = var v
sem (LPrim e) = evalPrimF e
sem (Pair t1 t2) = ProdI (sem t1) (sem t2)
sem (Snd t) = sem t >>> Snd
sem (Fst t) = sem t >>> Fst
sem (Lam t) = let x = sem t in (Curry (SwapP >>> x))
sem (App t1 t2) = (ProdI (sem t1) (sem t2)) >>> Apply
sem (Let t c) = let evc = sem (Lam c)
evt = sem t in
ProdI evc evt >>> Apply
sem (InL t) = sem t >>> InL
sem (InR t) = sem t >>> InR
sem (Case t1 t2 t3) = Copy >>> BifP (sem t1) Id >>>
Distrib >>> BifC (sem t2) (sem t3) >>> CocopyComposing this with the semantic interpreter from combinators to BCCs, we get:
interp : {ctx : List Ty} -> {ty : Ty} ->
(b : BCC g) -> Term ctx ty -> g (b.ty (ctxToProd ctx)) (b.ty ty)
interp b t = eval' b (sem t)We have formulated a translation from the STLC into an arbitrary BCC.
This was mostly painless, except for when it came to
translating constructors that involve context manipulation. Even writing
this blog post has fallen to the 80:20 90:10 95:5
rule, with the majority of the code being straightforward except for the
parts involving shuffling variables and binders.
It's worth reflecting on why this is so difficult. Categories don't have a first-class notion of variable context or binding operations, so when we're translating from a calculus that does, we need some way of turning binders and variables into morphisms. Doing so, however, makes our semantics more awkward and verbose, and can lead to an explosion of code size.
But what if there was another way? What if instead of translating into categorical combinators, we had a way of giving a semantics for the lambda calculus directly in terms of multicategories? Rather than dealing with the impedance mismatch between contexts and products, our semantics would be a homomorphism on the context, preserving its structure.
This is what we will look at in the next few blog posts, and what will become one of the main themes of the series. And if the idea of working with multicategories sounds daunting, then don't worry, the next blog post will start at the very beginning - with fixpoints of functors and free monads.
]]>As I've recently announced on Twitter, I'm starting a new blog series at the intersection of type theory, category theory, and functional programming.
The correspondence between lambda calculus and bicartesian closed categories is well known, and functional programmers have been using it to great extent. What is less widely known is how to extend this correspondence beyond just lambda calculi. In other words:
Our approach to this will be entirely algebraic (for a very general notion of 'algebraic'). We will represent our syntax using an inductive type, our semantics as an algebra over the type, and our interpreter as a fold connecting the two.
This approach is remarkably scalable. We will see how categories, multicategories, bicategories, and double categories can be all be represented as (indexed) functors over an appropriately chosen category. Using tools from recursion schemes, this will give us generic evaluators for a very wide range of structures.
On the language side, we will start with combinators and build up to simply typed, polymorphic, and dependently-typed languages. At each step we will implement an interpreter between the language syntax and its categorical semantics.
We will use Idris2 as our language, but write our code in a style accessible to Haskell programmers. (Most of the code in the first part of the series should be translatable to Haskell too.)
To start, let's retrace some familiar ground and look at a typed combinator language for bicartesian closed categories. We will interpret our combinator language into an arbitrary BCC, then show how to translate from the simply typed lambda calculus into combinators in the next blog post.
These first two blog posts are meant as a high level introduction to the basic tools and methodology that we'll be using through the series, and we will revisit these ideas step-by-step in subsequent posts.
You can find the full code for this post here.
We'll start with a typical representation of free categories in Haskell - a free category over functions.
data Path : (g : Type -> Type -> Type) -> Type -> Type -> Type where
Id : Path g a a
Cons : g b c -> Path g a b -> Path g a cThe first parameter 'g' corresponds to some type of Idris functions. 'a' and 'b' then correspond to the source and target types of the function, Id is the identity function, and Comp is a formal composite of functions.
In our case we will use the set of Idris functions
Idr : Type -> Type -> Type
Idr a b = a -> bBut we can also instantiate it with various useful categories from functional programming, such as Kleisli categories over a monad.
Kleisli : (Type -> Type) -> Type -> Type -> Type
Kleisli m a b = a -> m bThis representation isn't as general as it could be, though.
And since we have access to dependent types, let's formulate what it means to be a free category in general, not just free over Idris types.
Graph : Type -> Type
Graph obj = obj -> obj -> TypeThe definition of a free category stays the same, but our type becomes more informative
data Path : {obj : Type} -> Graph obj -> Graph obj where
Id : {a : obj} -> Path g a a
Cons : {a, b, c : obj} -> g b c -> Path g a b -> Path g a cA term of a free category is nothing other than a path constructed from composing individual edges of a graph.
You might notice the correspondence between this type, and that of Lists
data List : Type -> Type where
Nil : List a
(::) : a -> List a -> List aWhich motivates the idea that a category is a typed monoid.
The evaluator for a free category is very similar to a fold for a list, except that we replace each edge with a function rather than an element.
eval : Path Idr a b -> Idr a b
eval Id = id
eval (Cons f g) = f . (eval g)We will now go from a free category to a free category with products, coproducts, and exponentials. For readers new to category theory, we will go through each of these properties in more granular detail in subsequent blog posts. But for now we will define them all in one go.
We can then define our bicartesian category over types as:
data BCC : Graph Type -> Graph Type where
-- Embedding a primitive is now a separate operation
Prim : k a b -> BCC k a b
-- Identity arrow: a → a
Id : {a : Type} -> BCC p a a
-- Composition of arrows: (b → c) → (a → b) → (a → c)
Comp : {a, b, c : Type} -> BCC k b c -> BCC k a b -> BCC k a c
-- Product introduction: (a → b) → (a → c) → (a → (b * c))
ProdI : {a, b, c : Type} -> BCC k a b -> BCC k a c
-> BCC k a (b, c)
-- First projection: (a * b) → a
Fst : {a, b : Type} -> BCC k (a, b) a
-- Second projection: (a * b) → b
Snd : {a, b : Type} -> BCC k (a, b) b
-- Coproduct introduction: (b → a) → (c → a) → (b + c → a)
CoprodI : {a, b, c : Type} -> BCC k b a -> BCC k c a
-> BCC k (Either b c) a
-- Left injection: a → (a + b)
InL : {a, b : Type} -> BCC k a (Either a b)
-- Right injection: b → (a + b)
InR : {a, b : Type} -> BCC k b (Either a b)
-- Exponential elimination:
Apply : {a, b : Type} -> BCC k ((a -> b), a) b
-- Currying: (a * b → c) → (a → (b ⇨ c))
Curry : {a, b, c : Type} -> BCC k (a, b) c -> BCC k a (b -> c)
-- Uncurrying: (a → (b ⇨ c)) → (a * b → c)
Uncurry : {a, b, c : Type} -> BCC k a (b -> c) -> BCC k (a, b) c(One important caveat is that our data-type now represents a free f-algebra rather than a free category in the strict sense. We'll talk more about the distinction in future posts, but for now I'll abuse notation and keep calling both concepts by the same name.)
Defining an evaluator is as simple as it was before, we just match each constructor to the corresponding Idris function
eval : BCC Idr a b -> Idr a b
eval (Prim f) = f
eval Id = id
eval (Comp f g) = (eval f) . (eval g)
eval (ProdI f g) = \c => ((eval f) c, (eval g) c)
eval Fst = fst
eval Snd = snd
eval (CoprodI f g) = \c => case c of
Left l => (eval f) l
Right r => (eval g) r
eval InL = Left
eval InR = Right
eval Apply = uncurry apply
eval (Curry f) = curry $ eval f
eval (Uncurry f) = uncurry $ eval fSince we'd like to work with more general categories, let's define a record for storing our evaluator. If we were working in Haskell, we'd be using a typeclass here.
record Category (g: Graph Type) where
constructor MkCat
id : {a : Type} -> g a a
comp : {a, b, c : Type} -> g b c -> g a b -> g a c
prod : {a, b, c : Type} -> g c a -> g c b -> g c (a, b)
fst : {a, b : Type} -> g (a, b) a
snd : {a, b : Type} -> g (a, b) b
coprod : {a, b, c : Type} -> g a c -> g b c -> g (Either a b) c
left : {a, b : Type} -> g a (Either a b)
right : {a, b : Type} -> g b (Either a b)
apply : {a, b : Type} -> g (a -> b, a) b
curry : {a, b, c : Type} -> g (a, b) c -> g a (b -> c)
uncurry : {a, b, c : Type} -> g a (b -> c) -> g (a, b) cWe adjust our evaluator accordingly to use the new record type:
eval' : Category g -> BCC g s t -> g s t
eval' alg (Prim f) = f
eval' alg Id = alg.id
eval' alg (Comp f g) = alg.comp (eval' alg f) (eval' alg g)
eval' alg (ProdI f g) = alg.prod (eval' alg f) (eval' alg g)
eval' alg Fst = alg.fst
eval' alg Snd = alg.snd
eval' alg (CoprodI f g) = alg.coprod (eval' alg f) (eval' alg g)
eval' alg InL = alg.left
eval' alg InR = alg.right
eval' alg Apply = alg.apply
eval' alg (Curry f) = alg.curry (eval' alg f)
eval' alg (Uncurry f) = alg.uncurry (eval' alg f)Our new evaluator simply matches each construct with the corresponding record. Writing out all of these evaluators can become tiresome after a while, and indeed, in a few posts we will see how to do this entirely generically using recursion schemes.
As an example, let's create a record that packages up our earlier definition of the category of Idris functions.
IdrCat : Category Idr
IdrCat = MkCat
id
(.)
(\f, g, c => (f c, g c))
fst
snd
(\f, g, c => case c of
Left l => f l
Right r => g r)
Left
Right
(uncurry apply)
curry
uncurryWe could also instantiate our record with a few choices of categories, such as
-- Cokleisli category of a comonad
Cokleisli : (Type -> Type) -> Type -> Type -> Type
Cokleisli m a b = m a -> b
-- A static effect category over an applicative functor
StaticArrow : (Type -> Type) -> Type -> Type -> Type
StaticArrow f a b = f (a -> b)
-- Freyd category of an arrow
Freyd : (Type -> Type -> Type) -> Type -> Type -> Type
Freyd g a b = g a bIn general, it's rare that any of these constructions preserve all of our underlying structure (products, coproducts, exponentials), but we can always mix and match the syntax as needed.
Finally, let's step away from the category of Idris types and define a free bicartesian closed category in general.
Since we can't reuse Idris types, we now need to define a separate datatype for our type universe.
data Ty : Type where
Unit : Ty
Prod : Ty -> Ty -> Ty
Sum : Ty -> Ty -> Ty
Exp : Ty -> Ty -> Ty
N : TyAnd let's define type synonyms for them too
infixr 5 ~>
(~>) : Ty -> Ty -> Ty
(~>) = Exp
infixr 5 :*:
(:*:) : Ty -> Ty -> Ty
(:*:) = Prod
infixr 5 :+:
(:+:) : Ty -> Ty -> Ty
(:+:) = SumDefining the free BCC is just as before, but whereas we previously defined it over functions of inbuilt types, we now define it over a graph of our new type universe Ty.
data Comb : Graph Ty -> Graph Ty where
-- Primitives
Prim : k a b -> Comb k a b
-- Identity arrow: a → a
Id : {a : Ty} -> Comb p a a
-- Composition of arrows: (b → c) → (a → b) → (a → c)
Comp : {a, b, c : Ty} -> Comb k b c -> Comb k a b -> Comb k a c
-- Product introduction: (a → b) → (a → c) → (a → (b * c))
ProdI : {a, b, c : Ty} -> Comb k a b -> Comb k a c
-> Comb k a (b :*: c)
-- First projection: (a * b) → a
Fst : {a, b : Ty} -> Comb k (a :*: b) a
-- Second projection: (a * b) → b
Snd : {a, b : Ty} -> Comb k (a :*: b) b
-- Coproduct introduction: (b → a) → (c → a) → (b + c → a)
CoprodI : {a, b, c : Ty} -> Comb k b a -> Comb k c a
-> Comb k (b :+: c) a
-- Left injection: a → (a + b)
InL : {a, b : Ty} -> Comb k a (a :+: b)
-- Right injection: b → (a + b)
InR : {a, b : Ty} -> Comb k b (a :+: b)
-- Exponential elimination:
Apply : {a, b : Ty} -> Comb k ((a ~> b) :*: a) b
-- Currying: (a * b → c) → (a → (b ⇨ c))
Curry : {a, b, c : Ty} -> Comb k (a :*: b) c -> Comb k a (b ~> c)
-- Uncurrying: (a → (b ⇨ c)) → (a * b → c)
Uncurry : {a, b, c : Ty} -> Comb k a (b ~> c) -> Comb k (a :*: b) cThe main difference from before is that our primitives are no longer a simple embedding of Idris functions. Now we need a separate type for representing them. As an example, let's use the generators of a monoid over some base type:
data Prim : Ty -> Ty -> Type where
-- Unit
Z : Prim Unit Base
-- Multiplication
Mult : (Prod Base Base) BaseMost of our remaining definition stays exactly the same! This will become a running theme in this series, where adding extra generality will give us more power without too much extra complexity.
We can recover our earlier evaluator once we provide an interpretation of our type universe into Idris types
evalTy : Ty -> Type
evalTy U = Unit
evalTy (Exp t1 t2) = (evalTy t1) -> (evalTy t2)
evalTy (Prod t1 t2) = (evalTy t1, evalTy t2)
evalTy (Sum t1 t2) = Either (evalTy t1) (evalTy t2)
-- We'll interpret our base type as the type of naturals
evalTy N = NatWe can then define an evaluator. We'll start by interpreting in Idris functions, then generalise to records again. First we'll need to interpret the type of primitives.
evalPrims : Prims ty1 ty2 -> Idr (evalTy ty1) (evalTy ty2)
evalPrims Z = \() => 0
evalPrims Mult = uncurry (+)Then we'll write out interpreter for the rest of terms. We could have parametrised our eval function by evalPrims, but for now we'll keep things simple.
eval : Comb Prims ty1 ty2 -> Idr (evalTy ty1) (evalTy ty2)
eval (Prim f) = evalPrims f
eval Id = id
eval (Comp f g) = (eval f) . (eval g)
eval (ProdI f g) = \c => ((eval f) c, (eval g) c)
eval Fst = fst
eval Snd = snd
eval (CoprodI f g) = \c => case c of
Left l => (eval f) l
Right r => (eval g) r
eval InL = Left
eval InR = Right
eval Apply = uncurry apply
eval (Curry f) = curry $ eval f
eval (Uncurry f) = uncurry $ eval fThe main thing that's changed is that now instead of evaluating into Idris functions directly, we must first evaluate our source and target types. Thanks to the magic of dependent types, our compiler knows what the types of our evaluated combinators should be, so it's really hard to make a mistake here. This is something that will become invaluable once we start working with languages with more interesting notions of variable context.
Once again we would like to generalise from evaluating our
combinators into the category of Idris types to evaluating into
morphisms of an arbitrary category. Our types are now evaluated into
objects ty : Ty -> obj and our combinators are evaluated
into morphisms, whose source and target are calculated by first
evaluating the objects
Comb _ ty1 ty2 -> c (ty s) (ty t)
We'll package up the evaluator for objects in a more modular way later, but for now let's just stick the entire thing into our definition of a BCC:
record BCC {obj: Type} (g: Graph obj) where
constructor MkCat
-- evaluator for objects
ty : Ty -> obj
-- evaluator for morphisms
id : {a : Ty} -> g (ty a) (ty a)
comp : {a, b, c : Ty} -> g (ty b) (ty c) -> g (ty a) (ty b)
-> g (ty a) (ty c)
prod : {a, b, c : Ty} -> g (ty c) (ty a) -> g (ty c) (ty b)
-> g (ty c) (ty (a :*: b))
fst : {a, b : Ty} -> g (ty (a :*: b)) (ty a)
snd : {a, b : Ty} -> g (ty (a :*: b)) (ty b)
coprod : {a, b, c : Ty} -> g (ty a) (ty c) -> g (ty b) (ty c)
-> g (ty (a :+: b)) (ty c)
left : {a, b : Ty} -> g (ty a) (ty (a :+: b))
right : {a, b : Ty} -> g (ty b) (ty (a :+: b))
apply : {a, b : Ty} -> g (ty ((a ~> b) :*: a)) (ty b)
curry : {a, b, c : Ty} -> g (ty (a :*: b)) (ty c) -> g (ty a) (ty (b ~> c))
uncurry : {a, b, c : Ty} -> g (ty a) (ty (b ~> c)) -> g (ty (a :*: b)) (ty c)
-- evaluator for primitives
e : g (ty Unit) (ty N)
mult : g (ty (N :*: N)) (ty N)We've also included an evaluator for our primitives, in this case the multiplication and unit of a monoid.
Our final evaluator is then:
eval' : (bcc : BCC g) -> Comb Prims ty1 ty2 -> g (bcc.ty ty1) (bcc.ty ty2)
eval' alg (Prim Z) = alg.e
eval' alg (Prim Mult) = alg.mult
eval' alg Id = alg.id
eval' alg (Comp f g) = alg.comp (eval' alg f) (eval' alg g)
eval' alg (ProdI f g) = alg.prod (eval' alg f) (eval' alg g)
eval' alg Fst = alg.fst
eval' alg Snd = alg.snd
eval' alg (CoprodI f g) = alg.coprod (eval' alg f) (eval' alg g)
eval' alg InL = alg.left
eval' alg InR = alg.right
eval' alg Apply = alg.apply
eval' alg (Curry f) = alg.curry (eval' alg f)
eval' alg (Uncurry f) = alg.uncurry (eval' alg f)Overall, we can see that even as we've increased the complexity of the language, the structure of our evaluator has stayed the same. This is because at the core, an evaluator for an inductive type is nothing more than a homomorphism - a structure preserving map, whose behaviour is entirely determined by its actions on the generators of our algebraic theory.
And this is what makes the algebraic approach to programming so powerful. When we treat our language as an inductive type, we can reuse the same machinery we've developed for working with simpler algebraic structures such as monoids and semirings, but now apply it to more abstract structures, such as a typed combinator language for BCCs. As we will see through the course of this series, this scales to much more than just combinator languages, and even variable binding can be handled algebraically by working with inductive types over an appropriately chosen category.
In the next blog post we will have our first look at the simply typed lambda calculus and translate it into our combinator language, thus showing how to interpret the STLC into an arbitrary bicartesian closed category. After that, we'll start in earnest, and introduce the main tool we'll be using throughout the series - recursion schemes.
]]>