A partially ordered set is a set $P$ endowed with a binary relation $\leq$ on $P$ such that for all $p, q, r \in P$ we have:

1.) $p \leq p$ (reflexivity)

2.) $p \leq q$ and $q \leq r$ implies $p \leq r$ (transitivity)

3.) $p \leq q$ and $q \leq p$ implies $p = q$ (anti-symmetry)

If $P$ and $Q$ are partially ordered sets, we say that a function $f : P \to Q$ between them is monotone if for all $p_1, p_2 \in P$ with $p_1 \leq p_2$, we have $f(p_1) \leq f(p_2)$.

Several recent research papers (for example Lasp and BloomL) propose programming frameworks which utilize monotone functions as primitives of program composition, but they provide the user with a fixed set of monotone functions to work with. A type system capable of proving program functions monotone may enable the development of extensible versions of such frameworks.

Lately, I’ve been designing such a type system, for an extension of the simply typed lambda calculus. Since the programmer only cares about the monotonicity of a select group of functions, a special syntax construct, the sfun abstraction, serves as a signal to the type checker: unlike the simply typed world outside of the sfun abstraction, the body of the sfun abstraction is type checked using a special type system, which I call the lifted type system, in which monotonicity is tracked.

Reasoning about pointwise orderings on function spaces seems a bit heavy-weight and hasn’t been necessary for any of my use cases. An sfun is therefore first order; that is, both its return type and all of its argument types must be data types rather than function types. We would like to be able to prove that a multi-argument function is monotone separately in each of its arguments; that is, for $i \in 1..n$, if $p_i \leq p_i'$ then $f(p_1, \ldots, p_i, \ldots, p_n) \leq f(p_1, \ldots p_i', \ldots p_n)$.

The monotonicity of an sfun is typically derived from the monotonicity of the primitives used to implement it, which are also sfuns. Here are some example sfun primitives, addition and subtraction on integers:

1.) plus : $(x : Int, y : Int) \Rightarrow Int[\uparrow x, \uparrow y]$

2.) minus : $(x : Int, y : Int) \Rightarrow Int[\uparrow x, \downarrow y]$

An sfun type, written with $\Rightarrow$ rather than $\rightarrow$, names its formal arguments and also qualifies each one. A qualifier is an argument-specific constraint on the behavior of the function. In the above types, the qualifier $\uparrow$ is associated with arguments that are separately monotone and $\downarrow$ is associated with arguments that are separately antitone. The second argument of a binary function $f$ is separately antitone if $p_2 \leq p_2'$ implies $f(p_1, p_2) \geq f(p_1, p_2')$.

Terms outside of sfun abstractions are typed using a global typing relation, which, aside from an sfun abstraction typing rule, is not different from the typing relations we are familiar with. A global typing judgment has the following form.

A typing judgment of the lifted type system, used to type check the body of an sfun, has the following form:

Here the global type environment $\Gamma$ contains all of the variables bound outside of the sfun, the ambient type environment $\Omega$ contains the list of the sfun’s formal arguments, and the lifted type environment $\Phi$ contains those variables in $t$’s context which are bound inside the sfun. Before getting into the significance of lifted typing judgments, let’s look at a specific application of the global typing rule for sfun abstractions, which uses a single lifted premise.

Here we type a single-argument sfun abstraction $\tilde{\lambda} x:Int. plus(x,x)$. As you might have guessed, $\tilde{\lambda}$ is used rather that $\lambda$ to distinguish this as an sfun abstraction rather than a standard one. Examine the ambient and lifted type environments used in the premise. Perhaps surprisingly, the abstraction’s bound variable $x$ is entered into both environments. When variables occur in types, they are considered references to formal arguments rather than actual arguments; that is, an occurrence of $x$ in a type (for example $Int[\uparrow x]$) does not refer to some integer, but instead a “slot” named $x$ which expects to receive some integer from an external source. Inside the scope of the sfun abstraction, we would like the ability to refer to the abstraction’s formal argument $x$, and therefore we add $x : Int$ to the ambient environment. We would also like to include occurrences of $x$ as terms in the body of the abstraction; for these, we add the entry $x : Int[=~x]$ into the lifted type environment, to be used as a placeholder for the actual argument supplied to the formal argument $x$. Because references to formal arguments occur only in types, and references to actual arguments occur only in terms, we can add entries with the same name to both the ambient and lifted environments without creating any ambiguity.

The premise of the above rule application includes the strange looking types $Int[=~x]$ and $Int[\uparrow~x]$. Normally, we would expect occurrences of x, which serve as placeholders for the actual argument of the the function, to have type $Int$, and we would expect our abstraction’s body $plus(x,x)$ to have type $Int$ as well. This traditional approach to typing a function abstraction characterizes the operational behavior of a single function after it has been applied. Unfortunately, this isn’t adequate for reasoning about properties such as monotonicity, which involve multiple calls to the same function. My approach instead takes the perspective of inside of a function, before it has been applied. Lifted typing then characterizes the structure of a function as the composition of its constituent parts. In the above example, an occurrence of the variable $x$ in the term $plus(x,x)$ has type $Int[=~x]$, meaning that it is a function which takes the value provided to $x$ (the enclosing sfun’s formal argument) as an input, and produces that value unchanged as a result. We ultimately care about the input/output relation of this function, and so the concrete values which inhabit this type are set-of-pairs function representations. The type $Int[=~x]$ happens to be a singleton type, containing the set of pairs $\{ (0,0), (1,1), (-1,-1), (2,2), (-2-2), \ldots \}$.

The sfun application $plus(x,x)$ is viewed as a function composition, where the outputs of the functions represented by the two occurrences of $x$ are forwarded into the left and right arguments of the sfun $plus$. The domain of this composite function matches the domain $x:Int$ of the enclosing sfun, which it inherits from the two occurrences of $x$. Since $plus$ returns an $Int$, so does the composite function. The premise of the above typing rule application tells us that $plus(x,x)$ has type $Int[\uparrow~x]$, but this premise must be derived. How do we go about proving that the composite function $plus(x,x)$ is monotone?

First, pretend that the two occurrences of $x$ reference different formal arguments $x_1$ and $x_2$. Holding the left formal argument fixed gives a single-argument function $plus(-,x_2)$, which the type signature of $plus$ tells us must be monotone. $x_1$, representing the identity function on integers, is clearly monotone, since for all integers $z_1, z_2$ with $z_1 \leq z_2$, we have $id(z_1) = z_1 \leq z_2 = id(z_2)$. $plus(x_1, x_2)$ is then the composition of two monotone functions, which itself must be monotone. The same reasoning tells us that $plus(x_1,x_2)$ is monotone as a function of $x_2$ when $x_1$ is held fixed. $plus(x_1, x_2)$ is therefore monotone separately in both $x_1$ and $x_2$. However, we are interested in $plus(x,x)$, which is the function we get when we contract $x_1$ and $x_2$ into a single argument, supplying both of $plus$’s “slots” with the same value. Contracting two arguments of a function which are both separately monotone results in a new argument which is also separately monotone, and so we can conclude that $plus(x,x)$ has type $Int[\uparrow~x]$.

The lifted sfun application typing rule utilizes two binary operators $\circ$ and $+$ on qualifiers, which describe how monotonicity is propagated across function composition and argument contraction. The above example utilized the facts that $= \circ \uparrow$ is equal to $\uparrow$ and $\uparrow + \uparrow$ is equal to $\uparrow$. These operators are defined as lookup tables, recording a set of predefined facts about the propagation of monotonicity.

I’ll wrap things up by leaving you with one of the central features of my calculus. Namely, that the “global world” outside of an sfun abstraction is viewed as a degenerate subset of the “lifted world” inside the sfun abstraction. A globally well-typed sfun application is viewed as a projection onto this degenerate subset. Inside the sfun abstraction, we track the way in which each term depends on the sfun’s arguments, but terms originating outside of the sfun (both literal constants and occurrences of variables from the global type environment $\Gamma$) depend on the sfun’s arguments in a specific way: they are not affected by them at all. So, for any sfun with ambient environment $\Omega$, we can view the literal integer $1$ as a constant-valued function which, given any valuation of $\Omega$, produces the value one as a result. Of course, constant functions are monotone, and so a lifted subtyping relation allows 1 to occur in any context where Integer-valued functions with monotone dependence on the ambient environment $\Omega$ are expected. I view this as a weird refinement type system. Instead of starting with a simply typed system and decomposing its base types into preorders to induce a subtyping relation, I started with a simply typed system and positioned its base types as refinements of base types in a system with larger types (larger in that they denote larger sets of values). Consider the ambient environment $\Omega = x:Int$. Letting $Int[?~x]$ be the type of Int-valued functions which share the enclosing sfun’s formal parameter $x$, the following diagram decomposes the type $Int[?~x]$ into refinements. The red arrows indicate that projection from $Int[?~x]$ into the refinement $Int$ plays a special role. Still curios? See this paper for motivating examples, a full formalization, and a soundness proof.