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 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?