I’m not going to write much about how to use modal type theory here, because I just did a whole lot of that in the Narya documentation. You should go read it, and try it out!

• Modal type theory
• Modal parametric discreteness
• External parametricity

But I do want to comment on a few choices related to previous blog posts, and on my use of AI agents in coding it.

• I went with the syntax (x :□| A) → B for modal function-types. Only generating modalities have names, so if you want to annotate a variable by a composite of modalities you would in general have to separate their names by a space as in (x :△ □| A). However, it seems that often we give modalities single-character names, so I implemented a simplification that if all the modalities have single-character names, you can run them together as in (x :△□| A) and Narya will split them up for you.

• The syntax I settled on for keys is M #key. I like this because being postfix, it looks like a “property” or a “version” of M, which it is, and the symbol # it uses is on a standard US keyboard. (I like all syntax to at least have an equivalent version that can be typed on a standard US keyboard without fancy input methods; unfortunately I broke that rule with the names of the modalities for built-in mode theories, although at least you can rename them with a command-line flag.)

• For window modalities and modal field projections, I stuck with the same kind of modal annotations rather than introduce anything new: match (x :□| _) [ ... ] and (x :□| _) .fld. Although it may be a bit uglier that some other possibilities, I think it reduces the cognitive load on the user (which is already heavy in a modal type theory) to use the same syntax every time a term is being checked in a locked context.

• The above choice means that to define a record type with a modal field, you must use the self variable syntax for record types!

• Claude’s function to strip keys off an environment did not work. I tried writing the same function in a different way, but that didn’t work either. Eventually I settled on another way that I’m pretty confident works. However, it seems hard to justify semantically, as it involves using “imaginary faces” of cubes that temporarily exist but eventually get canceled by a degeneracy. (This doesn’t happen in plain modal type theory, which is semantically fine, only in the more experimental version with “discrete modalities”.)

In general, over the past month Claude has gotten better at doing what I want, or at least I’ve gotten better at getting it to do what I want. For instance, it’s been a long time since it tried to use Obj.magic or claim that a possible case was impossible. I think it’s partly because it’s recording some of the things I tell it in its internal memory about the project. (And also the models are probably continuing to improve; I had a brief promotional access to Fable for a couple of weeks.) It’s very good, for instance, at generating the boilerplate code for implementing new mode theories, given a description in words of the desired theory, which is very helpful given that all mode theories have to be implemented in OCaml so far. And I’ve learned, as everyone else also says, that when you want it to do anything substantial, it makes a big difference if you explicitly ask it to “make a plan” first and then give it feedback on its plan before it starts implementing.

However, I still can’t rely on it to come up with algorithms, or even to fill in the details of algorithms. If I give it a clear and precise description of the algorithm I want, it’s usually impressively good at implementing it. But if my description is vague or missing pieces, then sometimes it will spin for a long time trying to figure out how to fill it in, or come back to me and complain that it’s stuck – or, which is maybe worse, it will make guesses about how to fill things in, which compile and look plausible, but often turn out to be subtly wrong. I’ve had to fix a fair number of Claude-introduced bugs.

To be fair, though, Claude is also quite helpful at finding bugs, at least after I’ve discovered a test case. Sometimes it can even fix them, although as often as not I can think of a better fix myself. But tracing through the code to find exactly where and why an error is getting emitted is one of my least favorite parts of programming Narya, and Claude is very good at doing it for me.

Claude is also good at finding ways to speed up the code, which I’ve never been very good at. If you haven’t built Narya for a while, you may notice that the test suite runs substantially faster.

On balance, Claude has definitely saved me a lot of time: Modal Narya would definitely not be ready for use today without it. And I believe that, after all the back and forth, the code quality is comparable to what I would have produced myself. (Of course, I also make mistakes all on my own!)

I do have to discipline myself to look over all the code that it writes. It’s tempting to just trust it, especially when it also writes tests that pass; but I’ve been burned by doing that too many times. I don’t try to read and understand exactly everything the code is doing line by line, particularly the parts that are doing things like type-level arithmetic to make the parameters work out correctly: in those cases I can be fairly confident that anything that compiles is correct. But I do try to understand at a high level what the code is doing, and make sure that I agree with it. Most of the time there are some changes I want to make, sometimes minor, sometimes more substantial. And it matters to me that I “own” the Narya codebase, in the sense that I have a good idea of all the moving parts and how they fit together, even if I didn’t write it all myself.

I am also fairly impressed at how well Claude can write Narya code for new blackbox tests: it can’t have a very big library of examples to be drawing from because there just isn’t very much Narya code in the world yet. Apparently Claude has somehow “learned how to program” in a way that is, if not completely language-independent, adaptable to new languages without much difficulty. I’m curious how much of Claude’s knowledge about Narya syntax comes from reading the existing Narya code in the other blackbox tests, how much comes from reading the Narya documentation (which is, of course, right there in the same repository), and how much comes from reading the Narya source code – but I suppose I’ll never know.

One thing I don’t let Claude do, by the way, is write the documentation. I’m sure it could do a passable job, and sometimes it offers to; but to me the documentation is a creative product, like a novel or a mathematical paper, and I want it to be written by a human who thought at least a little about every word. Maybe that’s old-fashioned and maybe I’ll change my mind in the future, but at the moment that’s how I feel.

Anyway, enough about AI. We had a little demo/tutorial here at CT26 and folks were excited about the modal type theory features. I’m looking forward to seeing what people can do with them. Please give them a try, and send along any feedback!

def Σ (A : Type) (B : A → Type) : Type ≔ sig (
  fst : A,
  snd : B fst )

The other uses a “self variable” belonging to the record type itself, with the fields accessed using the usual field projection syntax from that variable:

def Σ (A : Type) (B : A → Type) : Type ≔ sig (
  x .fst : A,
  x .snd : B (x .fst) )

(You can’t mix the two syntaxes: you have to pick one or the other and use it for all the fields.)

Although self variables are a common way to access members and methods in mainstream object-oriented programming languages, they aren’t particularly common in proof assistants. But Narya not only permits them for record types, it mandates them for codatatypes. The only way to define streams is

def Stream (A : Type) : Type ≔ codata [
| x .head : A
| x .tail : Stream A ]

My original reason for using self variables was that in displayed type theory, we wanted to consider a kind of codatatype that uses the self variable in a different way than just projecting out its fields. In particular, we have the coinductive definition of semi-simplicial types:

def SST : Type ≔ codata [
| X .z : Type
| X .s : X .z → SST⁽ᵈ⁾ X ]

However, in the process of implementation I discovered that self variables are much easier to deal with than field variables. For instance, rather than the types of the fields being stored as a telescope, each in a longer context than the previous one, they can all be stored separately in a context that is only one variable longer (the self variable). So in the internals of Narya, everything is self variables; the translation from field variables (when the user writes the first syntax for a record type) happens at typechecking time.

Today I realized another benefit of self variables. Namely, field variables are kind of funny in that they look like variables, but they are not subject to alpha-equivalence. If you rename the fields of a record type, you get a different record type: isomorphic to the first one, but different. This, in turn, prevents arbitrary alpha-equivalence from being applied to other ordinary variables in enclosing binders.

Normally, if I have a nested λ-abstraction such as

x y z ↦ f x y z

I’m free to rename the variable y to anything I want, as long as it doesn’t shadow an outer variable such as x, at the cost of possibly also renaming other inner variables such as z. For instance, I can write that abstraction as

x w z ↦ f x w z

and also

x z z′ ↦ f x z z′

This order of alpha-renaming is convenient when printing a term, transforming the internal De Bruijn representation into a named variable one: as we descend through abstractions, at each point we choose a name for the bound variable that doesn’t conflict with any previously used names for outer variables. Thus, at the point of (re)naming y we are free to choose z, and then later we get to z and we just choose a different name for it there.

This is what breaks if field variables can’t be renamed. An equivalent way to write the above definition of Σ is

def Σ : (A : Type) (B : A → Type) → Type ≔ A B ↦ sig (
  fst : A,
  snd : B fst )

But in the λ-abstraction

A B ↦ sig ( fst : A, snd : B fst )

the ordinary variable B can’t be renamed to fst, because it would conflict with the inner field variable fst. We can’t print Σ as

A fst ↦ sig ( fst′ : A, snd : fst fst′ )

because that would be a different record type, with a field called fst′ rather than fst.

One might think of trying to rename “backwards”, renaming any outer variables that conflict with a field variable name. But aside from the difficulty of implementing something like that (if we’re displaying the term by a normal recursive traversal, other parts of the term referring to that outer variable by its original name might already have been displayed), the outer variable could also be a non-renameable field variable.

For instance, here’s a definition written using self variables that can’t be written directly using field variables:

def foo₁ : Type ≔ sig (
  x .fst : Type,
  x .snd : sig (
    y .fst : Type,
    y .snd : x .fst ))

If we try to write it with field variables, we get stuck:

def foo₂ : Type ≔ sig (
  fst : Type,
  snd : sig (
    fst : Type
    snd : ? ))

The ? is supposed to refer to the outer field variable fst, but that is shadowed by the inner field variable fst, and we can’t rename either of them. The only thing we can do is something like

def foo₃ : Type ≔ sig (
  fst : Type,
  snd : let outer_fst ≔ fst in sig (
    fst : Type
    snd : outer_fst ))

But it’s a bit much to expect a pretty-printer to insert let-bindings. So if the user writes the above definition of foo₃, then internally it gets normalized (making the let-binding disappear) and represented like foo₁, and the pretty-printer gets stuck trying to print it like foo₂. Thus, having the option of a user-facing syntax that uses self-variables is necessary for the pretty-printer to have something to output in this case. Probably it would stick with field variables for the outer record type, and then when it reaches the inner one and discovers a conflict, it falls back to self variables for that:

def foo₄ : Type ≔ sig (
  fst : Type,
  snd : sig (
    y .fst : Type
    y .snd : fst ))

Now, I should admit that most other proof assistants would not let you write any of these definitions, so the question of field variable alpha-equivalence doesn’t arise. In proof assistants like Rocq, Agda, and Lean, a record type definition is a top-level declaration that can’t appear as a term inside any other definition. Interestingly, the language feature I know of that comes closest to what Narya allows is OCaml’s labeled tuples:

fst:int * snd:(fst:int * snd:string)

However, these are not dependently typed, so the issue of names doesn’t come up.

I should also admit that although Narya will let you write foo₁, foo₃, and foo₄, the question of how to print them doesn’t come up at present, because record types are generative and nominal. That is, all of those definitions define a new type foo (or whatever) that doesn’t reduce to any previously existing thing such as sig ( ... ); instead the ≔ sig ( ... ) serves to specify the behavior of foo. However, it’s useful to be able to inspect the definitions of existing types without having to search for their definition, and I’m working on an extension that will print them. In that case, this issue will arise, and the printer will fall back to self variables in case of a conflict of field names, as I described above. (And in fact, I discovered this issue while working on that extension: Claude wrote some code that uniquified the field names, producing fst′ and so on, and I said Hey, that’s not right!)

Until now, I always thought of self-variable syntax for records (as opposed to codata) as a bit of an odd beast. I implemented it in response to a request from a user (who can identify themselves if they wish) who wanted to write some code that (I thought) was at least a little semantically suspect, referring to the self variable of a record in a non-field-access way similar to the codata definition of SST, and I’ve always been ambivalent about it. However, the realization that self variables are necessary to consistently print all nested record types makes me much happier about them (although when we get around to implementing consistency checks like termination and positivity, we should probably check that the self variable of a record type is only used to access its fields, and at least issue a warning if it is not). Perhaps we should even deprecate field variables!

They’re impressively good at GADT hacking, e.g. doing arithmetic on type-level nats and other stuff to ensure that types match up. And the presence of the strong type information means that I’m more confident in the results they produce: in many cases as long as the function has the right type, and the OCaml compiler accepts it, and a cursory examination indicates that it has the correct recursive structure, I feel like I can be pretty sure it’s right without following all the type-level arithmetic myself.

However, they do like to try to circumvent the type system. On one project Claude made lots of calls to Obj.magic, OCaml’s unsafe coercion function with type 'a -> 'b that doesn’t change the runtime representation but just tells the compiler “trust me”. It claimed they were all fine because the runtime representations agree; it was obviously wrong. It also liked to close off difficult cases with exceptions, claiming they were unreachable, when they obviously were not. And it was very lazy: it kept telling me that what I wanted was too big of a project to accomplish “in one session” until I shouted at it that yes, it’s a big project, and I want you to GET STARTED ON IT. I expect a more skilled AI-user would be able to guide it past these issues more smoothly, but I’m managing.

I mentioned in a previous post that it’s great for generating boilerplate, like functors between type-level free categories. It’s also great for implementing little features that I’ve wanted to do for a while but never had the time, like this pull request that allows you to specify different “default variable names” for particular canonical types. That one required understanding Narya’s parser and postprocessor as well as the readback and printing functions; I was impressed at how well Claude managed that.

For the moment, I’m keeping a tighter rein on parts of the code that involve serious mathematical understanding of the typechecking and normalization algorithm. But I did ask Claude to help me past a sticky point in the implementation of normalization for modal type theory with nonparametric modalities, reimplementing a recursive function (that I originally wrote) to strip the keps off of an environment to handle intermediate operations in several different ways. I haven’t yet successfully completed the implementation, but Claude’s contribution looks promising, although it does still have some issues that are work in progress.

In other news, Ambrus and Chaitanya are visiting this week and we’ve made some real progress on proving that the universe is fibrant in HOTT. One of these days I’ll finally post about how that relates to modal type theory.

Modal datatypes

Like most type formers, modal operators can be classified as positive or negative. The positive ones are simpler and were the only ones included in the original multimodal dependent type theory. If □ is a positive modal operator, the idea is that a variable of type □ A can be “destructed” into an ordinary variable of type A that is annotated by the modality (corresponding to) □. In premise-conclusion type theory syntax, this is written as follows (from the MTT paper):

The main thing to note is how we replace the element M₀ of the modal type ⟨μ|A⟩ by a variable y that belongs to A but is annotated with the modality μ.

In multimodal Narya, positive modalities are not built-in, but can be defined by the user as a special case of a datatype with modal constructor(s). More generally, any of the arguments of a constructor can be annotated with a nontrivial modality, in which case when we match against that constructor, the pattern variable corresponding to that argument becomes similarly annotated. For instance, here’s a definition of an ordinary positive modal operator:

def □ (A :□| Type) : Type ≔ data [
| box. (x :□| A) ]

There is some punning going on here: the □ in the annotations :□| is the name of a modality (a morphism in the mode theory 2-category), which lives in a different namespace from user-defined constants, while the □ being defined is a user-defined constant (a modal datatype). I regard the possibility of such punning as a good argument for this notation for modal variable annotations, although of course it allows the user to shoot themselves in the foot by creating mismatches instead.

Given this definition, here is the proof that □ is functorial:

def □map (A B :□| Type) (f :□| A → B) (u : □ A) : □ B ≔ match u [
| box. x ↦ box. (f x) ]

In the single branch of this match, the variable x is □-annotated. Therefore, since f is also □-annotated, f x is also, and thus we can apply the constructor box. to it. (More precisely, the argument of the constructor box. is checked in a □-locked context, and we can access f and x in that context because their annotation matches the lock.)

This is great, but to get all the desired behavior of modal operators in general we need a stronger version of their elimination rule:

The difference here is that the term M₀ in the modal type ⟨μ|A⟩ is in a context that’s locked by some other modality ν, and then the variable x that it’s destructed into is annotated by the composite modality ν ∘ μ. This generality is necessary, for instance, when proving that modal types depend functorially on modes: if μ and ν are composable modalities, then to define a map from ⟨ ν | ⟨μ|A⟩ ⟩ to ⟨ ν ∘ μ | A ⟩ we first destruct on ν, and then we get an element of ⟨μ|A⟩ annotated by ν and we have to destruct that, requiring the above generalized elimination rule. This extra modality ν is sometimes called a “window” modality because we “look through it” to find the modality μ to destruct.

The question is, (how) should the window modality should be notated in a Narya match? If we are matching against a free variable, there is no need to notate it at all, since the context annotation on that variable must also be the window modality. But Narya also allows matches on arbitrary terms, and in that case the term doesn’t determine the window modality; indeed, we can’t even typecheck the term until we know the window modality.

Here are some possibilities I can think of for notating a window modality ◇:

match (M :◇| _) [ box. x ↦ ? ]
match M :◇| _ [ box. x ↦ ? ]
match M return (_ :◇| _) ↦ _ [ box. x ↦ ? ]
match M through ◇ [ box. x ↦ ? ]
match M under ◇ [ box. x ↦ ? ]
match M behind ◇ [ box. x ↦ ? ]

The first three don’t require any new keywords, only re-using the same variable annotation syntax. (The return clause is necessary for a dependent match against a non-variable term anyway, and is allowed for non-dependent matches with a _ as the output.) These three syntaxes seem logical to me, but I think they’re also a bit ugly. The discriminee of a match must synthesize a datatype, so under normal circumstances it would never need to be ascribed; so we can put a _ there as the type, but that looks noisy. We could allow putting the actual type there instead too, of course, but that would nearly always be redundant information.

The last three look less ugly to me, but they all involve introducing a new keyword such as through, under, or behind.

Anyone have any opinions?

Modal codata and record types

Negative modalities were introduced to an MTT-like theory in Modalities and Parametric Adjoints, and appear to require more structure on the relevant modality. The original paper used a parametric right adjoint, but using ordinary adjoints is simpler and covers the majority of examples, and that’s what I’m planning for multimodal Narya. In this case, the rules as I wrote them in Semantics of multimodal adjoint type theory are:

To be “sinister”, a modality μ must have a right adjoint μ†. The first, introduction, rule, is then the same as that for the positive modality associated to μ†; but the elimination rule uses μ instead.

In multimodal Narya, negative modalities are also not built-in, but can be defined by the user as a special case of a codata or record type with modal fields. And more generally, any of the fields of a codata or record type can be annotated by an adjunction of modalities.

But since there are two modalities in an adjunction, it’s already not entirely obvious how to notate the definition of such a codatatype. If the adjunction is ♭ ⊣ ♯ as in spatial type theory, then we could annotate the “self variable” of the field by the left adjoint ♭:

def ♯ (A : Type) : Type ≔ codata [
| (x :♭| _) .unsharp : A ]

The annotation by ♭ makes sense because in the elimination rule, i.e. when projecting out the field of an element of ♯ A, that element must be in a ♭-locked context. Annotating the self variable with its type is not currently allowed, but it would also be required if we wanted to implement “indexed codatatypes”.

However, we could instead try to annotate the output by the right adjoint:

def ♯ (A : Type) : Type ≔ codata [
| x .unsharp :♯| A ]

This annotation makes sense because in the introduction rule, i.e. when defining an element of ♯ A, the value of .usharp must be defined in a ♯-locked context, i.e. it “has type” :♯| A.

One problem with the second version is that the :♯| notation conflicts with the use of | to separate multiple fields of a codatatype, especially if the modality ♯ is replaced by a composite of named generating modalities, or has a longer name. This seems like a poor reason to reject it in the abstract (since we could change that notation instead), but we need some reason to choose one or the other.

Anyway, there’s a more serious problem with modal codatatypes. In Narya, field names are not scoped: when you write x .fst, Narya doesn’t know what codata or record type fst refers to until it synthesizes a type for x and inspects its definition. This generally works perfectly with bidirectional type checking, and means you can freely use fields of the same name for different record types without any worry about whether they will conflict or which of them is “opened” at any time. (Similarly, constructors don’t know what datatype they belong to, and hence must always be used in a checking context.)

However, in order to synthesize a type for x, Narya needs to know its context. And in the case of a modal field, the element being projected out of is supposed to be typechecked/synthesized in a locked context. So how should Narya figure out the modality to lock by?

One option would be to continue overloading modal ascription syntax:

(x :♭| _) .unsharp

This has the same pros and cons as the similar syntaxes for window modalities in match, above.

Another option would be to incorporate the modality in the name of the field:

x .♭.unsharp

Adding information to field names (which never contain internal periods themselves) has some precedent in the syntax for higher coinductive types (and although that syntax is arguably ugly itself, I haven’t thought of anything better). And we could also use this in defining modal codatatypes:

def ♯ (A : Type) : Type ≔ codata [
| x .♭.unsharp : A ]

However, if we did this, there would be a potential conflict with higher coinduction: a field declaration like .♭.ee could mean either a ♭-modal field named ee or an ee-dimensional higher field named ♭ (both dimension letters and modality names belong to different namespaces than field names). The latter could be disambiguated by .♭..e.e, though, so we could default .♭.ee to mean the former (and I think actual ambiguity would be exceedingly unlikely to arise in practice).

Finally, another approach would be to try to synthesize “just enough” of x to find which codatatype it belongs to, and then inspect that to find the modality to lock its context to actually synthesize the whole thing. However, in general “just enough” couldn’t be guaranteed to be any less work than synthesizing the whole thing, so it seems like this could add significant extra overhead to typechecking.

We could probably manage it so that if x synthesizes fully in an unlocked context (as for an ordinary non-modal field), it doesn’t need to be synthesized twice, so this wouldn’t impact performance of non-modal fields. But if we did take this approach, it would probably be a good idea to also allow something like (x :♭| _) .unsharp, to allow the user to eliminate the double typechecking and improve performance with an explicit annotation.

Anyone have any thoughts?

In a fully dependently-typed language, it’s theoretically possible to eliminate all errors statically. If you can write a sufficiently detailed type for a function that basically says “this function does exactly what it’s supposed to do”, then as soon as you define a function of that type that compiles successfully, you can be absolutely sure (at least insofar as you trust the compiler) that it will, in fact, do exactly what it’s supposed to do. There are various problems with this theoretical dream, but I still find it useful as an ideal touchstone of typed programming.

One of the reasons we often can’t achieve that dream is that we may not be programming in a fully dependently typed language. Whether it’s practical yet to write large-scale code in an actually dependently typed language is a discussion for another day; suffice it for now to say that at present I am not. Narya is written in OCaml, a language which is in many ways a joy to program in, but it is not fully dependently typed: in general, types can’t depend on terms. However, types can depend on other types, and the type system of OCaml is flexible enough that we can encode a whole separate layer of “type-level terms” for our types to depend on.

This is a well-known technique in OCaml (and other languages that support it, like Haskell). I’m using it for lots of things in Narya, but one of the most important is static scoping.

Well-scoped indices

Like many implementations of type theory, Narya represents variables (in typechecked terms) by De Bruijn indices. However, in Narya all De Bruijn indices are all intrinsically well-scoped. That is, it’s impossible for the code to accidentally create a De Bruijn index that’s too large and points outside all the enclosing binders: the OCaml typechecker won’t allow it.

This is accomplished by indexing terms by a “phantom type” that records the length of their context, as a “type-level natural number”. Here is how we encode the natural numbers as types:

type zero = private Dummy_zero
type 'a suc = private Dummy_suc

(If you’re going to read this blog you should probably know at least basic OCaml syntax.) Thus, among the usual types int, string and so on, we now also have types zero, zero suc, zero suc suc, and so on, which we view as a copy of the natural numbers. Now we can define the type of De Bruijn indices as a GADT depending on the length of their context:

type _ index =
  | Top : 'a suc index
  | Pop : 'a index -> 'a suc index

This is just the usual definition of the “finite types” in dependent type theory, but now with the indexing natural number being a type rather than an element of a type of natural numbers. Thus we have the following indices:

• there is nothing in zero index
• Top : zero suc index
• Top : zero suc suc index and Pop Top : zero suc suc index
• Top : zero suc suc suc index and Pop Top : zero suc suc suc index and Pop (Pop Top) : zero suc suc suc index

and so on. Now when we define terms, we use these indices to denote variables:

type _ term =
  | Var : 'a index -> 'a term
  ...

and voila: it’s impossible for De Bruijn indices to be out of scope.

Dimension-indexed indices

In fact, what what Narya actually does is more complicated than this. In observational higher type theories, at least the way Narya implements them, each “variable” in the context can actually be a collection of variables forming a cube of some dimension. An ordinary single variable is a zero-dimensional cube. A one-dimensional cube consists (in the arity-2 case) of three variables: two endpoints and a path.

(x₀ : A) (x₁ : A) (x₂ : Id A x₀ x₁)

For instance, these are what we add to the context when defining an equality of functions in Id (A → B) f₀ f₁, since that identity type is (isomorphic to)

(x₀ : A) (x₁ : A) (x₂ : Id A x₀ x₁) → Id B (f₀ x₀) (f₁ x₁)

When we write this on a page, or even in proof assistant code, we write the variables x₀, x₁, x₂ in linear order, and usually think of simply abstracting over three ordinary variables one at a time. But one of the insights that makes Narya work is that internally, it’s better to treat these three variables together as a “bundle”, using a data structure that associates them directly to the faces of a cube (more on that in some other post, maybe), and only linearize them at the boundary of concrete syntax when interacting with the user. This eliminates a whole class of potential bugs that could arise from inconsistent ways to order the faces of a cube, and makes the logic more intuitive and geometric: you are always just iterating over the faces of a cube, with no need to think about the order in which it happens.

Now, however, when we put a whole cube of variables into the context at once, we need more information to access a single variable: not just a De Bruijn index, which points to the whole cube, but a face of that cube. This introduces a new source of potential “scoping” errors: what if the face has the wrong dimension to match the cube in the context?

Fortunately, we can also eliminate this possibility statically. We represent dimensions as types: for now you can just think of them as another copy of the type-level natural numbers above. Faces of a cube are then indexed by their domain and codomain, for instance an element of (zero suc, zero suc suc) face is a 1-dimensional face of a 2-dimensional cube (of which there are four). And the parameter of a term, that above was just the length of a context, now becomes a type-level list of dimensions – in fact, a backwards list. Here are the constructors of type-level backwards lists:

type emp = private Dummy_emp
type ('xs, 'x) snoc = private Dummy_snoc

Thus, for instance, here is a type-level backwards list of type-level natural numbers corresponding to [1; 2; 0]:

(((emp, zero suc) snoc, zero suc suc) snoc, zero) snoc

One final change is to parametrize the type of indices by the dimension that some index points to in a type-level backwards list of dimensions:

type (_, _) index =
  | Top : ('n, ('a, 'n) snoc) index
  | Pop : ('n, 'a) index -> ('n, ('a, 'k) snoc) index

Now we can say the variables that appear in terms are determined by an index and a face of the same dimension:

type _ term =
  | Var : ('n, 'a) index * ('k, 'n) face -> 'a term
  ...

and the OCaml typechecker will guarantee at compile-time that we never have a mismatch. (This isn’t exactly what’s in the Narya code, but it’s the basic idea.)

Free categories

My current project is to enhance Narya with Multimodal Type Theory. (I always intended to do that, but I’m doing it now because I have hopes that it will be useful in completing the implementation of HOTT; more on that later.) In MTT, contexts aren’t built just out of typed variables, but also locks arising from modalities. Specifically, each context has a mode, and if μ : p → q is a modality (mode morphism) then a q-context can be μ-locked to become a p-context.

Of course, this opens up yet another class of potential bugs: the source or target of a lock modality might not match up correctly. And so, of course, I set out on a quest to eliminate such errors statically.

Actually – no, I didn’t, not to start with. At first, I put in the locks without any static checking. And I got things mostly working, but there were some weird bugs that I didn’t entirely understand, but which seemed like they had to do with putting the wrong modalities or modes in the wrong places. So, instead of spending the time tracking down those specific bugs, I decided to rip everything apart and put in static modality-dependence in the context. This had the result of not only squashing the bugs I can see now, but preventing any future such bugs from occurring.

This may seem like a strange way to code, but it’s worked for me numerous times. In particular, when I do this, the bugs I started out looking at do, in fact, get fixed, even though it’s not always obvious to me exactly at what point I fixed them! Sometimes I have a guess about more or less the point at which they got fixed, but other times I have no idea. The latter is what happened with modal locks: to make the code compile under the new statically-typed locking regime, I had to rewrite enough of it more or less from scratch that I still have no idea where the bug was in the old version. But it doesn’t matter, because the OCaml typechecker promises me that the new version is free of (those) bugs.

Personally, I find this kind of coding to be a joy. Among other things, it means that I spend more of my time thinking about how things should work and doing them correctly, rather than trying to figure out why something isn’t working. And it’s also very category-theoretic, which of course appeals to me as a category theorist.

Why is it category-theoretic? I mean that partly in Tom Leinster’s sense that doesn’t refer at all to categories: it solves problems in a conceptual way by moving to a higher level of generality. But more concretely, this approach tends to incorporate more of the category-theoretic framework of mathematical descriptions of type theory into the implementation.

Static context locking is a case in point. The parameter of a context should now be a type-level backwards list that contains two kinds of elements: dimensions, representing variables, and modalities, representing locks. (Each modality, like each dimension, is itself represented by a type; I’ll say more in some other post about how that works.) In addition, each dimension is also paired with a modality, because variables in the context can be “modally annotated”.

However, not any old list of (modality, dimension) pairs and modalities is a valid “context length”, because the modes have to match up: if μ : p → q is a modality, then only a q-context can be μ-locked, and likewise only a variable in a q-context can be annotated by μ. Mathematically, these context lengths, or “type-level contexts”, are the free category generated by a quiver whose vertices are the modes, and with two kinds of edges: each modality μ : p → q yields a “lock” edge from p to q, while each pair (μ , n) of a modality μ : p → q with a dimension n yields a “variable” edge from q to q (adding a variable doesn’t change the mode of the context).

The foundation of static context locking is, therefore, a library for type-level free categories. Doing this right required a fair amount of boilerplate, but fortunately these days AI makes it easy to generate boilerplate. Here is the definition of type-level categories, and here is the free category on a quiver (whose morphisms are “paths” of edges in the quiver).

Finally, as usual, once we have a good abstraction, it turns out to be useful for lots of things. For example:

• When extending a context by a telescope, we “compose morphisms” in this “context category”.

• There is a functor from the category of modes to this “context category” which makes every modality into a lock. Locking a context is then just composition with the image of some modality under this functor. (This is less trivial than it seems because for technical reasons, the basic “lock” constructor actually just locks by a generating modality.)

• There is also a functor in the other direction that discards all variables and composes up the locks in a context. This is important when looking up a variable in a context: we need the composite of all the locks to its right to know what sort of “key” 2-cell is required to unlock it.

Multimodal Narya is not yet ready for release, but to whet your appetite here is some code that now compiles under the mode theory for an idempotent comonad □, exhibiting the functoriality and monad operations:

def □ (A :□| Type) : Type ≔ data [ box. (x :□| A) ]

def □map (A B :□| Type) (f :□| A → B) : □ A → □ B ≔ [ box. x ↦ box. (f x) ]

def ε (A :□| Type) (u :□ A) : A ≔ match u [ box. x ↦ x ]

def △ (A :□| Type) (u :□ A) : □ (□ A) ≔ match u [ box. x ↦ box. (box. x) ]

def □ε∘△ (A :□| Type) (u :□ A) : Id (□ A) (□map (□ A) A (ε A) (△ A u)) u
  ≔ match u [ box. x ↦ refl (box. x) ]

def ε□∘△ (A :□| Type) (u :□ A) : Id (□ A) (ε (□ A) (△ A u)) u ≔ match u [
| box. x ↦ refl (box. x)]

My current project is to enhance Narya with Multimodal Type Theory. (I always intended to do that, but I’m doing it now because I hope that it will be useful in completing the implementation of HOTT; more on that later.) I’ll have more to say about the implementation later, but right now I’m pondering some questions of concrete syntax.

Syntax for modes

In modern modal type theories, the modal behavior is parametrized by a mode theory: a 2-category whose objects are called modes and whose morphisms are called mode morphisms or modalities. There is a separate ordinary type theory at each mode, and the modalities induce modal operators mapping between them: a modality μ : p → q can induce a modal operator taking p-types to q-types.

In the literature on modal type theory, one tends to find judgments annotated by mode, such as Γ ⊢ A typeₚ or Γ ⊢ A type @ p. In the concrete syntax of a proof assistant (at least, of Narya), the only judgment the user interacts with is a typing judgment. But it would be quite annoying to have to constantly write x :ₚ A or x : A @ p.

I think a workable solution to this is to say that the names of modes are the same as the names of the corresponding universes of types at that mode. Thus, if there is only one mode, that mode is called Type. If there is another mode of “discrete types”, as in dTT, we could call that mode Disc, and so on. Then when we use one of these universe-names, it indicates directly which mode the corresponding type lives at, and the modes of essentially all other judgments should be inferrable.

Syntax for modal variables

The way modern modal type theories incorporate the modalities is that some variables are annotated by some modality. In general, a variable in a context or judgment at mode q can be annotated by a modality μ : p → q, in which case the type of that variable must live at mode p (in a context which is “locked” by the modality μ, but that’s a story for another day). Semantically, such a variable has the covariant modal operator associated to μ applied to its type, but syntactically it is a judgmental structure used to give rules for that modal operator as a type former.

There are two ways that these modal annotations are generally denoted syntactically in the literature. One is to modify the typing colon. For example, in crisp/spatial type theory the modal variables are denoted x ∷ A. The corresponding modal operator, say ♭, can then be defined as an inductive type generated by a constructor with a modal argument:

def ♭ (A ∷ Type) : Type ≔ data [
| flat. (x ∷ A) : ♭ A ]

If there are multiple modalities, this style requires additional “kinds of colons”. There are a limited number of Unicode colon-like operators, but of course we can make more by combining characters:

(x :~ A) (y :: B) (z :# C) (w ∷♯ D)

and so on.

This approach has the advantage of conciseness. However, it has several drawbacks:

• There are, to be sure, an unbounded number of colon-operators, but it seems a little awkward to have to keep thinking of a new one whenever we need a new modality, and we’ll quickly run out of the nicest-looking ones like ∷.

• Are :: and ∷ two different operators, or is the second a Unicode-variation of the first? What characters are allowed in a colon-operator? Narya’s existing lexer allows x:A to mean x : A because : is an ASCII symbol while x and A are identifiers. I don’t want to give that up, but without modification the same wouldn’t be true of x∷A, which would be inconsistent and surprising.

• We need a “name” to refer to each modality, for instance in error messages like ♯-annotated variable is inaccessible behind ♭ lock. We could use the colon-operators as names, like :#-annotated variable is inaccessible behind ∷ lock, but that looks a little ugly and could be hard to understand. And if modalities had names that were different from their colon-operators, the user would have to remember which names go with which colons.

• Some mode theories are finitely generated but not finite, and the user (or whoever specifies the mode theory) can only be expected to explicitly give names or colon-operators to the generators. If the lock is a composite of generators, then we need to be able to say something like ♯-annotated variable is inaccessible behind ♭ ♭ ♭ lock, which looks even uglier and more confusing as :#-annotated variable is inaccessible behind ∷ ∷ ∷ lock.

The other syntax for modal annotations in the literature is the one in the MTT paper, where the type is annotated with the modality and a bar operator: x : (♭ | A). This solves all of these problems since we can use a more natural “name” for the modality such as ♭, and a sequence of names to represent a composite of modalities as in x : (♭ ♭ | A). I’ve resisted using this syntax on paper because I think it’s fairly verbose, but something like it may be unavoidable in an implementation.

I am thinking of simplifying it a bit by removing the parentheses around ♭ | A, since in practice an annotated variable is always inside outer parentheses anyway, as for instance in a modal function type (x : ♭ | A) → B x. And as long as the modality names are valid identifiers (not ASCII symbols), the Narya lexer would allow us to write this as (x :♭| A) → B x, which is not that far from the modified-colon approach. I’m curious if anyone else has thoughts.

One specific thing to note is that the names of modalities would (I think) be a separate category from other identifiers. In particular, even if ♭ is a modality name, one could also def ♭ to mean something inside the theory, without risk of parsing ambiguity since the : and | always bracket a modality name. Of course, defining ♭ to mean something totally different would be confusing, but we might very well want to use it for the modal operator defined as above:

def ♭ (A :♭| Type) : Type ≔ data [
| flat. (x :♭| A) : ♭ A ]

Syntax for key operators

To use a modally annotated variable, you have to “unlock” it with a “key” that is a 2-cell in the mode 2-category. In the simplest case, if μ : p → p is an endo-modality, then to use a variable x :μ| A you need to unlock it with a 2-cell α : μ ⇒ idₚ. More generally, if μ : p → q then x :μ| A can be unlocked with α : μ ⇒ ν if the context is “locked” by ν (I’m omitting what that means because I want to concentrate right now on syntax).

Many mode theories are locally posetal, so such 2-cells are unique when they exist. In that case, there’s no need for a syntax for them as they can be inferred automatically. But for a general mode theory, there might be multiple parallel 2-cells, so the user needs a way to specify which they want to use for unlocking.

Key operators have some formal similarities to higher-dimensional degeneracies, so I’ve been tempted to use a superscript syntax for them akin to Narya’s existing x⁽ᵉᵉ⁾ for degeneracies. However, on balance I think this would be too unwieldy: the superscripts would get too long to be easily readable.

One simple approach is a function-like prefix notation, so for instance α x would mean x unlocked with the key 2-cell α. (This also has a precedent in degeneracies, where refl x means the same as x⁽ᵉ⁾.)

In the case of a mode theory that’s finitely generated but not finite, where only the generating 2-cells have names, we need to derive names for the non-generating ones. I think we can get away without syntax for “vertical” composites of 2-cells (along 1-cells), because the key action of such a composite is just a composite of actions, so we can just write β (α x) instead of having a syntax for composing α and β.

Notating horizontal composition (along 0-cells) is more tricky. The simplest option would be something like α β x. As long as the names of 2-cells are not also available as identifiers, I think this would be technically unambiguous — but it could still be confusing, with α β f x meaning “act on the function-variable f with the horizontal composite of 2-cells α β, then apply the result to the argument x”.

A more verbose option would be for all key actions to be labeled by some keyword or symbol, such as key α x or 🗝️ α x. Then the first argument would always be a 2-cell, perhaps including a parenthesized (horizontal) composite of generating 2-cells: 🗝️ (α β) x.

We could combine the two options by saying that if the 2-cell argument is just a single generator, the key can be omitted: α x means 🗝️ α x, but 🗝️ (α β) x has no analogous abbreviated form. However, unlike the pure-key option, this would require that the names of 2-cells can’t be re-used for user definitions.

I’m especially curious if anyone else has thoughts about this. Which versions look best to you? If we need a “key” label, do you prefer the keyword key, the symbol 🗝️ (or 🔑), or something else?