A Preliminary Type- and Control-Flow Analysis for System F$_\omega$

Abstract

A type- and control-flow analysis is a program analysis that yields both type-flow information, approximating the types that may instantiate type variables, and control-flow information, approximating the values (especially $\lambda$- and $\varLambda$-expressions) that may be bound to variables. Moreover, each of the flows informs the other; control-flow establishes the types that may instantiate $\varLambda$-bound type variables by determining the $\varLambda$-expressions that flow to a type-application expression, while type-flow filters control-flow by rejecting the flow of values having static types that are incompatible (according to the type-flow information) with the static type of the receiving variable.

In previous work [1, 13, 14], we introduced a (monovariant) type- and control-flow analysis for System F (with recursion). While System F has an expressive type system and has served as a useful core calculus in which to express interesting language features, it only allows abstraction over types and does not allow abstraction over type constructors. Increasingly, researchers are looking at System F$_\omega$, with both term- and type-level abstraction over types of arbitrary kind, as a core calculus in which to explore advanced language features. Hence, we are motivated to define a type- and control-flow analysis for System F$_\omega$ that is able to analyze the rich structure of System F$_\omega$ types.

In this work, we present a preliminary type- and control-flow analysis for System F$_\omega$ (with recursion). As in previous work, we give both a specification-based formulation of the analysis, used to prove soundness of the analysis, and a flow-graph-based formulation, used to guide the implementation of an algorithm. While the macro structure of the development for System F$_\omega$ follows that for System F, moving to System F$_\omega$ introduces subtle challenges that have left some unanswered questions about the meta-theory. In particular, the decidability of type compatibility defined in terms of System F$_\omega$’s definitional type equivalence remains an open question. In order to be computable, our flow-graph-based formulation uses a restricted form of definitional type equivalence and performs a 0CFA at the type-level, yielding an analysis result that is less precise than the “best” (but as of yet, uncomputable) analysis result accepted by the specification-based formulation. Our soundness results have been formalized in the Coq proof assistant.

This work is based in part on the first author’s MS thesis [53].

Appendices

A Language

1.1 A.1 Additional Judgments

The various judgments given in Fig. 11 relate a program P to its constituent expressions, binds, right-hand-sides, values, bound expression variables, type expressions, type binds, type values, and bound type variables.

Fig. 11.

Constituent Judgments

B Type System

Parallel Reduction and $\boldsymbol{\mathfrak {a}}$-Equivalence. Although the definitional-type-equivalence judgment suffices for defining the type system and the two formulations of type- and control-flow analysis for System F$_\omega$, the meta-theory is greatly simplified by the introduction of a parallel reduction judgment (Fig. 12), which is a directed variant of definitional type equivalence. Parallel reduction is “one-way”, in the sense that an application of a function to an argument parallel reduces to the substitution, but not vice versa. Parallel reduction also requires that an indexed type variable only parallel reduces to itself (i.e., is not “up to $\mathfrak {a}$-equivalence”). To formally relate definitional type equivalence and parallel reduction, we introduce an explicit $\mathfrak {a}$-equivalence judgment (Fig. 12). The key property is that definitional type equivalence coincides with parallel reduction to $\mathfrak {a}$-equivalent reducts:

Fig. 12.

Elaborated Type Parallel Reduction and $\mathfrak {a}$-Equivalence

Typing Environments and Lookups. A typing environment (Fig. 13) records the index type variables and kinds of de Bruijn indices, maps type variables to an optional elaborated type and a kind, and maps expression variables to elaborated types. A entry corresponds to an abstract type variable, brought into scope by a , while an entry corresponds to a defined type variable, brought into scope by a , where is the elaboration of . Well-formedness of a typing environment ( ) requires that each elaborated type contained within is well-kinded (with kind ${\star }$ for an x : ‘q entry and with kind for an entry) with respect to the preceding typing environment, that the elaborated types of expression variables are locally closed (because expression variables are never bound within the body of a type-level function), and that all type variables are distinct. The requirement that all type variables are distinct, which is equivalent to a requirement that no introduced type variable shadows a type variable already in scope, ensures that no type-variable capture occurs when a defined type variable (whose elaborated type makes use of abstract type variables preceding it in the typing environment) is used after the abstract type variables are rebound (possibly with different kinds). For example, in the ill-formed typing environment , the type variable  is in scope, yet it’s elaborated type would be ill-kinded with respect to that typing environment.

Fig. 13.

Typing Environments, de Bruinj-Index Lookups, Type-Variable Lookups, and Expression-Variable Lookups for ANF System F$_\omega$

We have judgments (Fig. 13) for looking up de Bruijn indices ( ), type variables ( ), and expression variables ( ) in a typing environment. Looking up a de Bruijn index i in requires finding the $i^{{th}}$ entry of from the head (right) of the typing environment. One final subtlety is that the lookup of a defined type variable fails if it would transport a locally-open elaborated type across an entry. Again, this ensures that no capture, this time of a de Bruijn index, occurs. For example, in the well-formed typing environment , the type variable is in scope, yet it’s elaborated type  would be ill-kinded with respect to that typing environment. This is not restrictive; it simply requires one to $\texttt{tlet}$-bind de Bruijn-index type values within the body of the innermost type-level function for which they are needed.

Typing Rules (Figures 14, 15, 16, and 17)

Fig. 14.

Type System for ANF System F$_\omega$ (typing environments and elaborated types)

Fig. 15.

Type System for ANF System F$_\omega$ (type variables, type values, type binds, and type expressions)

Fig. 16.

Type System for ANF System F$_\omega$ (variables, values, right-hand sides, binds, and expressions)

Fig. 17.

Type System for ANF System F$_\omega$ (run-time type values, run-time values, run-time environments, stacks, and states)

C Specification-Based Formulation of TCFA

1.1 C.1 Auxiliary Judgments (Fig. 18)

Fig. 18.

Specification-Based TCFA (auxiliary judgments)

D Example Flow Analyses

Table 2. Remaining flow-analysis results for the System F$_\omega$ program given in Fig. 2b via 0CFA, specification-based TCFA, and flow-graph-based TCFA; partial results were given in Table 1