I recently completed a university course which featured Haskell and Agda (a dependent typed functional programming language), and was wondering if it was possible to replace lambda calculus in these with combinatory logic. With Haskell this seems possible using the S and K combinators, thus making it point-free. I was wondering what the equivalent was for Agda. I.e., can one make a dependently typed functional programming language equivalent to Agda without using any variables?
Also, is it possible to somehow replace quantification with combinators? I don’t know if this is a coincidence but universal quantification for example makes a type signature look like a lambda expression. Is there a way to remove universal quantification from a type signature without changing its meaning? E.g. in:
forall a : Int -> a < 0 -> a + a < a
Can the same thing be expressed without using a forall?
So I thought about it a bit more and made some progress. Here’s a first stab at encoding Martin-Löf’s delightfully simple (but inconsistent)
Set : Setsystem in a combinatory style. It’s not a good way to finish, but it’s the easiest place to get started. The syntax of this type theory is just lambda-calculus with type annotations, Pi-types, and a universe Set.The Target Type Theory
For completeness’ sake, I’ll present the rules. Context validity just says you can build contexts from empty by adjoining fresh variables inhabiting
Sets.And now we can say how to synthesize types for terms in any given context, and how to change the type of something up to the computational behaviour of the terms it contains.
In a small variation from the original, I’ve made lambda the only binding operator, so the second argument of Pi should be a function computing the way the return type depends on the input. By convention (e.g. in Agda, but sadly not in Haskell), scope of lambda extends rightwards as far as possible, so you can often leave abstractions unbracketed when they’re the last argument of a higher-order operator: you can see I did that with Pi. Your Agda type
(x : S) -> TbecomesPi S \ x:S -> T.(Digression. Type annotations on lambda are necessary if you want to be able to synthesize the type of abstractions. If you switch to type checking as your modus operandi, you still need annotations to check a beta-redex like
(\ x -> t) s, as you have no way to guess the types of the parts from that of the whole. I advise modern designers to check types and exclude beta-redexes from the very syntax.)(Digression. This system is inconsistent as
Set:Setallows the encoding of a variety of “liar paradoxes”. When Martin-Löf proposed this theory, Girard sent him an encoding of it in his own inconsistent System U. The subsequent paradox due to Hurkens is the neatest toxic construction we know.)Combinator Syntax and Normalization
Anyhow, we have two extra symbols, Pi and Set, so we might perhaps manage a combinatory translation with S, K and two extra symbols: I chose U for the universe and P for the product.
Now we can define the untyped combinatory syntax (with free variables):
Note that I’ve included the means to include free variables represented by type
ain this syntax. Apart from being a reflex on my part (every syntax worthy of the name is a free monad withreturnembedding variables and>>=perfoming substitution), it’ll be handy to represent intermediate stages in the process of converting terms with binding to their combinatory form.Here’s normalization:
(An exercise for the reader is to define a type for exactly the normal forms and sharpen the types of these operations.)
Representing Type Theory
We can now define a syntax for our type theory.
I use a de Bruijn index representation in the Bellegarde and Hook manner (as popularised by Bird and Paterson). The type
Su ahas one more element thana, and we use it as the type of free variables under a binder, withZeas the newly bound variable andSu xbeing the shifted representation of the old free variablex.Translating Terms to Combinators
And with that done, we acquire the usual translation, based on bracket abstraction.
Typing the Combinators
The translation shows the way we use the combinators, which gives us quite a clue about what their types should be.
UandPare just set constructors, so, writing untranslated types and allowing “Agda notation” for Pi, we should haveThe
Kcombinator is used to lift a value of some typeAto a constant function over some other typeG.The
Scombinator is used to lift applications over a type, upon which all of the parts may depend.If you look at the type of
S, you’ll see that it exactly states the contextualised application rule of the type theory, so that’s what makes it suitable to reflect the application construct. That’s its job!We then have application only for closed things
But there’s a snag. I’ve written the types of the combinators in ordinary type theory, not combinatory type theory. Fortunately, I have a machine that will make the translation.
A Combinatory Type System
So there you have it, in all its unreadable glory: a combinatory presentation of
Set:Set!There’s still a bit of a problem. The syntax of the system gives you no way to guess the
G,AandBparameters forSand similarly forK, just from the terms. Correspondingly, we can verify typing derivations algorithmically, but we can’t just typecheck combinator terms as we could with the original system. What might work is to require the input to the typechecker to bear type annotations on uses of S and K, effectively recording the derivation. But that’s another can of worms…This is a good place to stop, if you’ve been keen enough to start. The rest is “behind the scenes” stuff.
Generating the Types of the Combinators
I generated those combinatory types using the bracket abstraction translation from the relevant type theory terms. To show how I did it, and make this post not entirely pointless, let me offer my equipment.
I can write the types of the combinators, fully abstracted over their parameters, as follows. I make use of my handy
pilfunction, which combines Pi and lambda to avoid repeating the domain type, and rather helpfully allows me to use Haskell’s function space to bind variables. Perhaps you can almost read the following!With these defined, I extracted the relevant open subterms and ran them through the translation.
A de Bruijn Encoding Toolkit
Here’s how to build
pil. Firstly, I define a class ofFinite sets, used for variables. Every such set has a constructor-preservingembedding into the set above, plus a newtopelement, and you can tell them apart: theembdfunction tells you if a value is in the image ofemb.We can, of course, instantiate
FinforZeandSucNow I can define less-or-equals, with a weakening operation.
The
wkfunction should embed the elements ofxas the largest elements ofy, so that the extra things inyare smaller, and thus in de Bruijn index terms, bound more locally.And once you’ve got that sorted out, a bit of rank-n skullduggery does the rest.
The higher-order function doesn’t just give you a term representing the variable, it gives you an overloaded thing which becomes the correct representation of the variable in any scope where the variable is visible. That is, the fact that I go to the trouble of distinguishing the different scopes by type gives the Haskell typechecker enough information to compute the shifting required for the translation to de Bruijn representation. Why keep a dog and bark yourself?