I recently managed to get my MSFP2020 extended abstract uploaded to the arXiv (don’t worry, link to follow!). It took me this long because I finally need to cite it – which is to say, because everything’s taking me this long. But it’s about time I blogged at least a little about it and upped some related things into my own space.

History and Ideas

It’s been a long trip (…a decade and counting so far) and it’s far from over, but once upon a time I read the first paper on information effects¹, had an idea that matched some of my existing ones and have found myself feeling increasingly obligated to drag it across the line as I keep seeing more things come of it.

Perhaps the key idea of my own is: the information, in the Shannon sense, created by an [abstract] interpreter is the meaning of the program it interprets. Typecheckers very much included. But it’s also fair to say that as an effectful (effect-oriented?) hacker I’m further opinionated about how to exploit that!

The major things I’ve actually talked about so far are information aware type systems – a constraint-based way to present type systems that allows for careful accounting of information flow – and telescopic constraint trees, a representation of typechecking problems that is to some extent necessary for handling sufficiently dependent types. I can derive the trees (and the rules for them) from Information Aware rules, or even the typing rules from rules for building trees! While I definitely can’t do it mechanically, I can even have a go at reverse-engineering a type system from an example program and a worked example of typechecking it. And hopefully, if the work makes sense to you then you’ll be able to as well.

Telescopic constraint trees themselves aren’t new (as mentioned in the acknowledgements, Conor McBride got there first and they’ve spent a long time as folklore). The relationship between my presentation of them and my presentation of typing rules is new, and because it’s not fixed to one type system I’ve found myself in the awkward position of having to name a piece of folklore. There’s a good tutorial paper about applying the folklore to Hindley-Milner mentioned in the acknowledgements section, and I’ve cheerfully stolen the approach to generalisation (and the sequencing it requires) from it.

I’ve had a lot of fun with this, and I have some other old ideas to resurrect and throw through some of this machinery as well. Recently though I’ve been working on a collection of related logic languages (one of which I’m calling Nooblog²), with the goal of building the metalanguage for information aware type systems (and other related problems: elaboration needs some extra tricks for example).

Material

Here’s my MSFP2020 material, variously from arXiv, my own site and YouTube:

• MSFP2020 Extended Abstract – Information Aware Type Systems and Telescopic Constraint Trees
• Slides
• Talk Video

While I’m here, I’ll add some alternative bits and pieces, some older and some newer:

• Idris Developer’s Meeting 2021 mostly focuses on telescopic constraint trees including discussion of substructural languages and an observation about Quantitative Type Theory that Conor McBride and I had separately and got round to discussing in 2016
• SPLS October 2019 – Telescopic Constraint Trees is an earlier talk that contains some discussion of structural rules for telescopic constraint trees themselves, and of what happens when we discover a local metavariable actually needs a more global scope
• Information Aware Type Systems and Telescopic Constraint Trees [Extended Mix] has a worked solution (complete with some deliberately arbitrary choices) of a telescopic constraint tree problem

Several of these slides mention a Twitter account that I have since deleted. Email addresses should still be good, and contact details are on this site’s About page.

Acknowledgements

Finally, I should make some acknowledgements that I haven’t had room for elsewhere:

• First of all, Conor McBride, not just for the discussion and filling me in on the history, or even for having developed a telescopic constraint tree for Epigram 1, but also for the amount of personal support and encouragement they’ve given me over the years.
  • On which note, Adam Gundry also deserves a mention for the conversation in 2012 when he was still Conor’s PhD student! Adam, Conor and James McKinna’s Type Inference in Context is an excellent paper for anyone who wants to read a slightly more conventional take on this using Hindley-Milner as a minimal motivating system.
• Everybody who has reinvented telescopic constraint trees, and especially everybody who tried to get there when dependent types had provided the motivation but no answer was available. I have a story to tell about this (and the inevitability of it), and some year I’ll get it into a suitable state for a wide audience: those who don’t want to wait should consider that I build the trees by isomorphism and ask themselves what happens if a language is capable of reifying metavariable binders.
• Edwin Brady for plenty of useful chat and encouragement to give my first SPLS talk of 2019 (the part where I dual-wielded a microphone and the stick for pulling the screen shades down to point at the screen is not, technically, his fault).
• Chris Martens for helping me get started on the citation trail for something akin to the notion of moding I’m using. Also their online class on Twelf at the start of last year, which I should still post about!
• The MSP101 group and everybody who’s been part of it over the years for variously hosting and putting up with me.
• Sam Lindley for encouraging me to submit to MSFP2020 after the announcement at SPLS October 2019.
  • Both Sam and Max [New], Freelance Programme Chairs, as well as my reviewers and my shepherd Stephanie Balzer.
• Paolo Giarrusso for helping me refine my material for people who think less like me.
• Dominic Orchard for his enthusiasm and cheerleading.
• Clarissa Littler for discussion and support.
• My ex AJ for supporting and otherwise putting up with me during my 2019/early 2020 burst of activity.
• Everybody who’s ever put up with me producing an iPad with some slides loaded and asking “would you like to hear about my work?”, however much context they did or didn’t have!

There’s a common piece of advice when people learn to read typing rules: “read them clockwise”. I’m going to explain how to generalise this idea into a useful concept called a mode, but first let’s explain the advice itself!

(As a quick aside, I have some slight quirks in how I write variables in typing rules - this post explains what I do differently and why)

Reading Clockwise

Suppose I want to use this rule:

We can break it down into steps, reading the rule clockwise starting from the bottom-left.

This rule assumes we have some context Γ and we want to typecheck λx.e, a lambda with some variable x and the body e. Notice that we’ve taken not even a syntactic but a lexical slice out of the rule - Γ ⊢ e : τ is all one judgment/relation, so Γ ⊢ e on its own doesn’t really mean anything. It’s the variables Γ and e that matter.

To continue, we have to check the conditions above the line hold. In this case, that we can typecheck e in the context Γ, x : τp where we have no idea what type τp is yet but we call the resulting type τr

Finally we get our result type, τp → τr - and hopefully we found out what τp is on the way.

Clockwise is a Mode?

The “clockwise” rule of thumb relies on a simple trick: typechecking is the process of starting with some term (and some assumed context) and figuring out what valid type it has. Slightly informally, if we’re doing type synthesis/inference we don’t know that type yet and if we’re doing type checking then maybe we do, but that part’s less important for a moment.

Usefully, when we make a recursive check like in the Lam rule, we have the same situation again - the same parts of the typing relation are input, the same parts are output.

And because most type systems are syntax-directed¹, we can find the rule we need just by looking at the term - letting us write a recursive type checker by simple case analysis.

Modes

“Clockwise” the way I’ve just described it, complete with that commonality in uses above and below the line? It’s something called a “mode” ², and I might write that mode down  +  ⊢  +  : −. Here, + is a known parameter and − is an unknown we’re trying to find out. That doesn’t mean there can’t be any unknowns buried in something +, we don’t know what τp is when we typecheck that lambda body. But we do know that it’s the τp we introduced in that rule and not an “unknown unknown”!

But there are other modes we can use that Lam rule in, so let’s talk about them a bit? Here are some examples:

All of these things can be done with the same rules! As an old logic programming slogan says: “algorithm = logic + control”. Modes declare an important piece of control information without forcing us to detail things with step-by-step instructions.

Another important related concept from logic programming is the relationship between relations and procedures. Typing rules describe [part of] a relation, procedures implement specific ways of using a relation - and different modes often need different procedures to run efficiently.

As we’re talking about type systems in particular, I should also spell out clearly: bidirectional type systems work by limiting which rules can be used at which modes (“checking”, “synthesis”)!

Many Notions of Mode

There are many flavours of mode system out there - not least because logic programming has a wide and varied history! Something that is suitable for Prolog might be unsuitable for studying formal logics, because in Prolog a lot comes down to variable instantiation. Something suitable for studying formal logics is likely to be utterly unsuitable for Prolog: it’s turing complete and permits all kinds of things that formal logics normally avoid to have a tractable metatheory.

One extension I’ve found useful is one I call “refinement modes”, by analogy to refinement types. It comes from what you might call the “variable instantiation” side of the family and allows the mode for a particular variable to be “input, and it’s definitely a → but I don’t know the parameters”, or “output, and it’s a →…”. The Mercury language supports something like this, and I’ve used it in my own work.

Another important concept is ground mode - the mode in which everything is fully known and there are no (meta)variables in the data at all. Something at ground mode doesn’t need any hint of constraint solving, not even first-order unification! This is why it’s so much faster to write a typechecker for simply typed lambda calculus with annotated lambdas than to allow leaving off the type annotations.

Ground mode is also a link between functional and logic programming: functional programming normally works at ground mode. Given the Curry-Howard correspondance, arguably functional programming is 0th order logic programming!

Ack

Hopefully this has been some help to somebody out there! I’d like to thank a couple of people:

• Chris Martens is from a more logic-oriented background than I am, and I’d especially like to thank them for pointing me towards a useful citation trail for my MSFP2020 submission! After a short chase I ended up using these two papers:
  • Uday S. Reddy (1993): A typed foundation for directional logic programming
  • Ekkehard Rohwedder & Frank Pfenning (1996): Mode and termination checking for higher-order logic programs
• More importantly for this piece, Uma Zalakain let me know a slide or two about modes in my work made a big difference for how she thinks about type systems. It’s easy to lose track of what other people do and don’t know, both as fields expand and as we get older, stop being students and start forgetting where we even learned things. This post is an attempt to make something useful common knowledge, and without Uma’s feedback I wouldn’t have written it.

Continuing on from an earlier post, I’ve had to make up my own notation on occasion and I’d like to talk about some things that felt good but are probably mistakes in the long run.

Starting with this piece of smartarsery¹:

For reasons I’ll talk about in another post, the red branching shape in the middle is syntax for a “duplication constraint” - insisting that the context on the left is equal to both the contexts on the right. When it’s used to describe an otherwise-normal typechecker, this amounts to passing the left-hand context twice.

Hence the branch - it’s describing a branch in dataflow! But aside from the accessibility issues around colour-coding and bright red² this is a pretty bad idea for anything aside from pen and paper or whiteboard work. Why?

• I hacked the glyph up in LaTeX with negative hspace and the \langle character - I have no business expecting others to reverse engineer it!
• It uses superscripting and subscripting, so the duplicated contexts render smaller and the issues from the previous post crop up again
• For whiteboard work it often makes more sense vertically anyway

I do have a workaround for the super/subscript issue, I ended up needing this n-ary version anyway:

But for reasons involving quantities I’ve even perpetrated these!:

I think it’s time I start writing things like dup(τ)(τ,τ) or dup(τ){τ, τ, τ} instead.

I’ve changed a few things since I started giving talks again, I’ve got at least one more change on the way, and I figured it was worth talking about them so other people could see why I’ve made them and to comment on the tensions behind the status quo.

First of all, I’m extremely glad I let Conor McBride nudge me towards larger fonts on slides! I’ve found myself in a situation where the original speaking room overflowed and I wound up with people watching from a worrying viewing angle that put them at twice the expected viewing distance. So these days my Beamer slides pretty much default to \Large everywhere and so far it’s doing right by me. I figure I need a really good reason to dip into \large for a slide, let alone \normalsize or smaller.

But there’s a related problem that’s all over mathematical papers - superscripts and subscripts. I don’t think it’s too bad if I ask Pandoc to give me, say, π² or τ^f in the middle of a post rather than some slides, but in most settings the font gets smaller and smaller - 2²²² is actively uncomfortable.

Superscripts also play into another, more controversial issue in our notation. I used τ^f as an example because I often use it for a function’s type. Or at least I did - these days I try to use τf instead to avoid the scaling problem. But nice as that is when we’re doing a bunch of pen and paper work? It’s still a pain to read, especially for anybody who doesn’t manage to guess that not only is τf a function type, but τp is the type of a parameter and τr is a return or result type! The notation might be strictly formal, but the more intuition we can provide the better.

So what I’m trying to do where I can is use names like τfunction or - when I get to name it - Γbody. The names are more informative and the greek letters now have a clear purpose that applied all long.

Surprise! It’s Charles Simonyi’s Hungarian Notation!¹ We use τ and Γ to indicate the syntactic categories - the meta-level types, if you will - that our schematic variables refer to. If I wanted to wind up a certain kind of E.W. Dijkstra fan I might even compare them to BASIC-style sigils.

So what’s stopping me from doing this everywhere? Well, for one: it’s a pain when we’re writing to fit a page limit on paper. Page limits force us to spatially compress what we’re saying. Even if the variable names fit fine in a column, they might mean it takes an extra line or two to write a typing rule down. When we want to publish papers, the paper gets right in our way.

And okay, my handwriting’s both slow and ugly so if I’m calculating by hand… but I’m not a maths lecturer and I don’t often do that for an audience of more than one or two people. If I need to reproduce my working elsewhere, I’ve got time to typeset it and pick better variable names.

Looks like I’ve set myself up a new blog or something.

Or rather: I’ve spent long enough messing around with Hakyll and it’s about time I uploaded the basics so I can actually say “I have a blog”.

I’m happy enough with most of what I’ve bolted on so far - there’s a slightly-more-than-basic tagging system, I’ve got a decent draft facility nobody else’ll ever see, stuff like that. Haven’t given myself automatic LaTeX-to-PNG rendering yet (which I’m sure as hell going to need), but I shouldn’t let that get in the way of a proof of concept, right?