Definition of Fsub (System F with subtyping).

Authors: Brian Aydemir and Arthur Charguéraud, with help from Aaron Bohannon, Jeffrey Vaughan, and Dimitrios Vytiniotis.

Table of contents:

• Syntax (pre-terms)
• Opening
• Local closure
• Environments
• Well-formedness
• Subtyping
• Typing
• Values
• Reduction
• Automation

Syntax (pre-terms)

We use a locally nameless representation for Fsub, where bound variables are represented as natural numbers (de Bruijn indices) and free variables are represented as atoms. The type atom, defined in the Atom library, represents names: there are infinitely many atoms, equality is decidable on atoms, and it is possible to generate an atom fresh for any given finite set of atoms.

We say that the definitions below define pre-types (typ) and pre-expressions (exp), collectively pre-terms, since the datatypes admit terms, such as (typ_all typ_top (typ_bvar 3)), where indices are unbound. A term is locally closed when it contains no unbound indices.

Note that indices for bound type variables are distinct from indices for bound expression variables. We make this explicit in the definitions below of the opening operations.

We declare the constructors for indices and variables to be coercions. For example, if Coq sees a nat where it expects an exp, it will implicitly insert an application of exp_bvar; similar behavior happens for atoms. Thus, we may write (exp_abs typ_top (exp_app 0 x)) instead of (exp_abs typ_top (exp_app (exp_bvar 0) (exp_fvar x))).

Opening terms

Opening replaces an index with a term. This operation is required if we wish to work only with locally closed terms when going under binders (e.g., the typing rule for exp_abs). It also corresponds to informal substitution for a bound variable, which occurs in the rule for beta reduction.

We need to define three functions for opening due the syntax of Fsub, and we name them according to the following convention.

• tt: Denotes an operation involving types appearing in types.
• te: Denotes an operation involving types appearing in expressions.
• ee: Denotes an operation involving expressions appearing in expressions.

The notation used below for decidable equality on atoms and natural numbers (e.g., K === J) is defined in the Metatheory library. The order of arguments to each "open" function is the same. For example, (open_tt_rec K U T) can be read as "substitute U for index K in T."

Note that we assume that U is locally closed (and similarly for the other opening functions). This assumption simplifies the implementations of opening by letting us avoid shifting. Since bound variables are indices, there is no need to rename variables to avoid capture. Finally, we assume that these functions are initially called with index zero and that zero is the only unbound index in the term. This eliminates the need to possibly subtract one in the case of indices.

Many common applications of opening replace index zero with an expression or variable. The following definitions provide convenient shorthands for such uses. Note that the order of arguments is switched relative to the definitions above. For example, (open_tt T X) can be read as "substitute the variable X for index 0 in T" and "open T with the variable X." Recall that the coercions above let us write X in place of (typ_fvar X), assuming that X is an atom.

Local closure

Recall that typ and exp define pre-terms; these datatypes admit terms that contain unbound indices. A term is locally closed, or syntactically well-formed, when no indices appearing in it are unbound. The proposition (type T) holds when a type T is locally closed, and (expr e) holds when an expression e is locally closed.

The inductive definitions below formalize local closure such that the resulting induction principles serve as structural induction principles over (locally closed) types and (locally closed) expressions. In particular, unlike the situation with pre-terms, there are no cases for indices. Thus, these induction principles correspond more closely to informal practice than the ones arising from the definitions of pre-terms.

The interesting cases in the inductive definitions below are those that involve binding constructs, e.g., typ_all. Intuitively, to check if the pre-term (typ_all T1 T2) is locally closed we much check that T1 is locally closed, and that T2 is locally closed when opened with a variable. However, there is a choice as to how many variables to quantify over. One possibility is to quantify over only one variable ("existential" quantification), as in

  type_all : forall X T1 T2,
      type T1 ->
      type (open_tt T2 X) ->
      type (typ_all T1 T2)

or we could quantify over as many variables as possible ("universal" quantification), as in

  type_all : forall T1 T2,
      type T1 ->
      (forall X : atom, type (open_tt T2 X)) ->
      type (typ_all T1 T2)

It is possible to show that the resulting relations are equivalent. The former makes it easy to build derivations, while the latter provides a strong induction principle. McKinna and Pollack used both forms of this relation in their work on formalizing Pure Type Systems.

We take a different approach here and use "cofinite quantification": we quantify over all but finitely many variables. This approach provides a convenient middle ground: we can build derivations reasonably easily and get reasonably strong induction principles. With some work, one can show that the definitions below are equivalent to ones that use existential, and hence also universal, quantification.

We also define what it means to be the body of an abstraction, since this simplifies slightly the definition of reduction and subsequent proofs. It is not strictly necessary to make this definition in order to complete the development.

Environments

In our presentation of System F with subtyping, we use a single environment for both typing and subtyping assumptions. We formalize environments by representing them as association lists (lists of pairs of keys and values) whose keys are atoms.

The Metatheory and Environment libraries provide functions, predicates, tactics, notations and lemmas that simplify working with environments. The Environment library treats environments as lists of type list (atom * A).

Since environments map atoms, the type A should encode whether a particular binding is a typing or subtyping assumption. Thus, we instantiate A with the type binding, defined below.

A binding (X, bind_sub T) records that a type variable X is a subtype of T, and a binding (x, bind_typ U) records that an expression variable x has type U.

We define an abbreviation env for the type of environments, and an abbreviation empty for the empty environment.

Note: Each instance of Notation below defines an abbreviation since the left-hand side consists of a single identifier that is not in quotes. These abbreviations are used for both parsing (the left-hand side is equivalent to the right-hand side in all contexts) and printing (the right-hand side is pretty-printed as the left-hand side). Since nil is normally a polymorphic constructor whose type argument is implicit, we prefix the name with "@" to signal to Coq that we are going to supply arguments to nil explicitly.

We also define a notation that makes it convenient to write one element lists. This notation is useful because of our convention for building environments; see the examples below.

Examples: We use a convention where environments are never built using a cons operation ((x, a) :: E) where E is non-nil. This makes the shape of environments more uniform and saves us from excessive fiddling with the shapes of environments. For example, Coq's tactics sometimes distinguish between consing on a new binding and prepending a one element list, even though the two operations are convertible with each other.

Consider the following environments written in informal notation.

  1. (empty environment)
  2. x : T
  3. x : T, Y <: S
  4. E, x : T, F

In the third example, we have an environment that binds an expression variable x to T and a type variable Y to S. In Coq, we would write these environments as follows.

  1. empty
  2. [(x, bind_typ T)]
  3. [(Y, bind_sub S)] ++ [(x, bind_typ T)]
  4. F ++ [(x, bind_typ T)] ++ E

The symbol "++" denotes list concatenation and associates to the right. (That notation is defined in Coq's List library.) Note that in Coq, environments grow on the left, since that is where the head of a list is.

Well-formedness

A type T is well-formed with respect to an environment E, denoted (wf_typ E T), when T is locally-closed and its free variables are bound in E. We need this relation in order to restrict the subtyping and typing relations, defined below, to contain only well-formed types. (This relation is missing in the original statement of the POPLmark Challenge.)

Note: It is tempting to define the premise of wf_typ_var as (X `in` dom E), since that makes the rule easier to apply (no need to guess an instantiation for U). Unfortunately, this is incorrect. We need to check that X is bound as a type-variable, not an expression-variable; (dom E) does not distinguish between the two kinds of bindings.

An environment E is well-formed, denoted (wf_env E), if each atom is bound at most at once and if each binding is to a well-formed type. This is a stronger relation than the ok relation defined in the Environment library. We need this relation in order to restrict the subtyping and typing relations, defined below, to contain only well-formed environments. (This relation is missing in the original statement of the POPLmark Challenge.)

Subtyping

The definition of subtyping is straightforward. It uses the binds relation from the Environment library (in the sub_trans_tvar case) and cofinite quantification (in the sub_all case).

Typing

The definition of typing is straightforward. It uses the binds relation from the Environment library (in the typing_var case) and cofinite quantification in the cases involving binders (e.g., typing_abs and typing_tabs).

Values

Reduction

Automation

We declare most constructors as Hints to be used by the auto and eauto tactics. We exclude constructors from the subtyping and typing relations that use cofinite quantification. It is unlikely that eauto will find an instantiation for the finite set L, and in those cases, eauto can take some time to fail. (A priori, this is not obvious. In practice, one adds as hints all constructors and then later removes some constructors when they cause proof search to take too long.)