2.1 Gradual typing

Gradual typing allows the interoperability of statically typed and dynamically typed code. The original formalization by Siek & Taha (Reference Siek and Taha2006) defined gradual typing for a simply typed lambda calculus extended with dynamic types. Siek & Vachharajani (Reference Siek and Vachharajani2008) and Garcia & Cimini (Reference Garcia and Cimini2015) further investigated gradual typing in the presence of type inference.

In this paper, we consider the migration of programs in implicitly typed gradual languages. In Figure 4, we present the syntax and type system of one such language, ITGL, which is adapted from Garcia & Cimini (Reference Garcia and Cimini2015) and forms the basis for this work. In the syntax, c ranges over constant values, x over variables, $\gamma$ over constant types, and $\alpha$ over type variables. There are two cases for abstraction expressions, one where the parameter is annotated by $\star$ and one where it is not. The rest of the cases are standard. The type system will be explained below.

Figure 4. Syntax and type system of ITGL, an implicitly typed gradual language. The operations dom, cod, and $\sqcap$ are undefined for cases that are not listed here.

The presentation of ITGL in Figure 4 differs from the original in Garcia & Cimini (Reference Garcia and Cimini2015) in two ways. First, our syntax is more restrictive: we omit a case for explicit type ascription of expressions, and we do not allow arbitrary type annotations on abstraction parameters. We also do not consider let-polymorphism here. These restrictions are made to simplify our formalization later, but we show in Section 9 how they can be lifted. Second, the typing rules are parameterized by a statifier, ${\omega}$ , which is used in the full migrational type system later (Section 4). A statifier is a mapping that maps parameter names that have $\star$ s to static types, making an expression to have a more static type. The statifier specifies what static types to assign to parameters whose $\star$ annotations will be removed. For simplicity, we assume parameters have unique names. In the type system as defined in Figure 4, ${\omega}$ is always empty, corresponding to the type system in Garcia & Cimini (Reference Garcia and Cimini2015).

In the type system for ITGL in Figure 4, the typing rules for constants and variables are standard. There are two rules for abstractions, Abs for unannotated parameters which must have static types, and Absdyn for annotated parameters which may have dynamic types. In Absdyn, we use $or(\omega(x),\star)$ to return ${\omega}(x)$ if $x \in dom{(\omega)}$ or $\star$ otherwise. Therefore, if ${\omega}$ is empty, then $or(\omega(x),\star)$ will always be $\star$ .

Note that a statifier maps parameters to fully static types only, as can be seen from the definition of ${\omega}$ in Figure 4. As such, mappings such as $x\mapsto\star\rightarrow\mathtt{Int}$ or $y\mapsto\star\rightarrow\star$ do not belong to ${\omega}$ . This follows the spirit of Garcia & Cimini (Reference Garcia and Cimini2015) that inferred types should be fully static. Consequently, we cannot find an ${\omega}$ to make the expression $\lambda{x}:{\star}.{x\ x}$ well-typed, even though the expression $\lambda{x}:{\star\to\star}.{x\ x}$ is.

Typing applications is tricky, since dynamically typed arguments can be passed to functions with statically typed parameters and vice versa. For example, assuming the function, $\mathtt{succ}$ , has static type $\mathtt{Int}\to\mathtt{Int}$ , both of the following programs in our Haskell-like notation should be accepted by gradual typing.

The App rule accommodates this with the help of a consistency relation, $\sim$ , that dictates when two unequal types are compatible with each other. An application is well-typed if the domain of the LHS (i.e. the parameter type) is consistent with the RHS, and the type of the application is the codomain of LHS. The auxiliary functions dom and cod return the domain and codomain of a function type, respectively, or $\star$ for a dynamic type (reflecting the fact that $\star$ is equivalent to $\star\to\star$ ).

The gradual type consistency relation is defined in Figure 4 by four rules: C1 defines that consistency is reflexive, C2 and C3 define that a dynamic type is consistent with any type, and C4 defines that two functions types are consistent if their respective argument and return types are consistent. As a result, $\mathtt{Int}\to\mathtt{Int}\sim\mathtt{Int}\to\star$ but not $\mathtt{Int}\to\mathtt{Int}\sim\mathtt{Bool}\to\star$ , since the argument types are not consistent in the latter case. Note that the consistency relation is not transitive. Due to C2 and C3, transitivity would lead every static type to be consistent with every other static type, which is clearly undesirable.

Typing conditional expressions relies on the meet operation, $\sqcap$ , on gradual types. Intuitively, meet chooses the more static of two base types when one is $\star$ . For two equal static types, meet is idempotent. For two function types, meet is applied recursively to their respective argument and return types. The meet operation helps assign types to conditionals when the two branches might not have an identical type but still have consistent types. Intuitively, meet favors the type of the more static branch of the conditional expression.

2.2 Variational typing

Variational typing (Chen et al., Reference Chen, Erwig and Walkingshaw2012, Reference Chen, Erwig and Walkingshaw2014) enables efficiently inferring types for variational programs. A variational program represents many different variant programs that share some parts among each other and which can each be generated through a static process of selection.

The theoretical foundation for variational typing is the choice calculus (Erwig & Walkingshaw Reference Erwig and Walkingshaw2011), a formal language for representing variational programs. The essence of the choice calculus is that static variability in programs can be locally captured in variation points called choices, as demonstrated by the following example.

This program contains a choice named A with two alternatives, $\mathtt{succ}$ and $\mathtt{even}$ . We write $\lfloor e \rfloor_{d.i}$ to indicate the selection of the ith alternative of each choice named d in e. So, $\lfloor \mathtt{vfun} \rfloor_{A.1}$ yields the program $\mathtt{succ\,1}$ and $\lfloor \mathtt{vfun} \rfloor_{A.2}$ yields $\mathtt{even 1}$ . We call d.i a selector and use s to range over selectors. We call d.1 and d.2 the left and right selectors of d, respectively.

A decision is a set of selectors; we use $\delta$ to range over decisions. For each choice d, a decision contains only one or neither of d.1 and d.2. The elimination of choices extends naturally to decisions by selecting with each selector in the decision. An expression e is called plain if it does not contain any choices and is called variational if it does contain choices. A plain expression obtained by eliminating all choices in a variational expression is called a variant. For example, $\mathtt{succ\,1}$ is a plain expression and a variant of the variational expression $\mathtt{vfun}$ .

A variational expression may contain several choices. Choices with the same name are synchronized and independent otherwise. For example, the variational expression has two variants, $\mathtt{succ\,2}$ and $\mathtt{even\,3}$ , obtained by the decisions $\{A.1\}$ and $\{A.2\}$ , respectively. The program $\mathtt{succ\,3}$ cannot be obtained through selection and so is not a variant of this expression. On the other hand, the variational expression has four variants, and we can obtain the variant $\mathtt{succ\,3}$ with the decision $\{A.1,B.2\}$ .

In general, an expression with n distinct choice names can be configured in $2^n$ different ways. Since variational programs can easily contain hundreds or thousands of independent choice names (Apel et al., Reference Apel, Batory, Kästner and Saake2016), checking the type correctness of all variants is intractable by a brute-force strategy of generating all of the variants and typing each one individually (Thüm et al., Reference Thüm, Apel, Kästner, Schaefer and Saake2014). Variational typing solves this problem by sharing the typing process across all variants, which is achieved by defining and reasoning about variational types.

Variational types are types extended with choices. We define variational types in Figure 5. They include constant types ( $\gamma$ ), such as $\mathtt{Int}$ and $\mathtt{Bool}$ , type variables ( $\alpha$ ), function types, and choices over two alternatives.

Figure 5. Variational types, selection, and type equivalence.

All concepts and operations on variational expressions carry over to variational types. For example, Figure 5 defines selections on types. Selecting constant types (and type variables) with any selector yield themselves. For a function type, selection is recursively applied on the parameter type and return type. Selecting a choice type with a selector that has the same choice name ( $d.i$ ) will yield the ith alternative. The selection is recursively applied to the alternative to eliminate all choices with the same name. For example, if we do not recursively select, yields while $\mathtt{Int}$ is the expected result, which could be achieved by recursively selecting with A.1. Selecting a choice type with a selector ( $d_1.i$ ) that has a different choice name will apply the selection to both alternatives. Finally, selecting a type with a decision ( $s:\delta$ ) is recursively defined as first selecting the type with s and then selecting the resulting type with the decision $\delta$ .

It is natural to assign variational types to variational expressions. For example, has type . Similar to gradual typing, typing applications in the presence of variation is complicated by the fact that “compatible” types may not be syntactically equal. In particular, 1. the LHS is traditionally expected to be a function type but in variational typing may be a (nested) choice of function types, and 2. when checking whether the type of the argument matches the type of the parameter, we must take into account that either or both may be variational. For example, the type of the function on the LHS of $\mathtt{vfun}$ is , which is not a function type directly, but both variants of $\mathtt{vfun}$ , $\mathtt{succ 1}$ and $\mathtt{even\,1}$ , are well-typed.

Typing applications is supported in variational typing through the definition of a type equivalence relation (Chen et al., Reference Chen, Erwig and Walkingshaw2014), which is presented in Figure 5. Essentially, type equivalence specifies when a type can be transformed into another without affecting its semantics. The semantics of a variational type maps decisions to the variant plain types obtained by selecting from the type using the decision. For example, , and are all equivalent because selecting from each of them with $\{A.1\}$ yields the same type $\mathtt{Int}\to\mathtt{Int}$ and selecting from each of them with $\{A.2\}$ yields the same type $\mathtt{Int}\to\mathtt{Bool}$ . As a result, we can say that $\mathtt{vfun}$ has the type , which is a function type with the argument type $\mathtt{Int}$ matching the type of $\mathtt{1}$ . We can thus assign the type to $\mathtt{vfun}$ .

An important result of variational typing is that choice elimination preserves typing. More specifically, if e has the type V, then $\lfloor e \rfloor_{\delta}$ has the type $\lfloor V \rfloor_{\delta}$ for any decision $\delta$ . For example, $\lfloor \mathtt{vfun} \rfloor_{A.1}$ yields $\mathtt{succ\ 1}$ , which has the type $\mathtt{Int}$ , the same as $\lfloor V_{\mathtt{vfun}} \rfloor_{A.1}$ . An implication of this result is that the type of any variant can be easily obtained by making an appropriate selection into the result type of the variational program. Another important result of variational typing is that it is significantly faster than the brute-force approach.

4.1 Syntax

The syntax of expressions, types, and environments is given in Figure 7. The metavariables we use to range over the relevant symbol domains are listed at the top of the figure. For type variables, we typically use $\beta$ to denote the result type of a function application during constraint generation and $\kappa$ to denote fresh type variables generated during constraint generation and solving (see Sections 6 and 7). For choice names, we typically use A and B to denote arbitrary specific choices in examples and d as a generic metavariable to range over choices names in definitions.

Figure 7. Syntax of expressions, types, and environments.

The syntax of expressions, static types, and gradual types is repeated from Section 2.1. To this, we add variational types, which are static types extended with choices, and migrational types, which are gradual types extended with choices. Note that each top-level parameter is assigned a restricted form of migrational type, which is either a fully static type, a $\star$ , or a choice of restricted migrational types; however, the more general syntax defined in Figure 7 is needed during the typing process. In Section 9.1, we extend our framework to allow an arbitrary mix of $\star$ and static types for top-level parameters. We also define type context to facilitate our presentations of both the type system and proofs.

The type system relies on three kinds of environments: a type environment maps variables to migrational types, a substitution maps type variables to variational types, and a variational statifier maps variables to variational types. As described in Section 2.1, a statifier ${\omega}$ records one way of making a program more static (by removing some subset of $\star$ annotations). A variational statifier ${\Omega}$ instead compactly encodes all possible statifiers for an expression. Since we want migration in our formalization to assign static types to parameters whose $\star$ annotations are removed, ${\Omega}$ maps parameters to variational types, but not migrational types.

Substitutions map type variables to variational types rather than migrational types since substituting dynamic types is unsound. For example, suppose we have $\mathtt{f}\mapsto\alpha\to\alpha\to\alpha\to\alpha$ and $x\mapsto\star$ in $\Gamma$ . Now, when typing the application $\mathtt{f x}$ , we will substitute $\{\alpha\mapsto\star\}$ , yielding $\star\to\star\to\star$ as the type of $\mathtt{f x}$ . However, this implies that $\mathtt{f x 2 True}$ is well-typed, even though this violates the initial static type of f. The idea of substituting type variables with variational types but not migrational types is reminiscent of Guha et al., (Reference Guha, Matthews, Findler and Krishnamurthi2007), where only certain contracts could be used to instantiate parametric contract variables. Type substitution, written as $\theta(M)$ , is defined in the conventional way.

4.2 Type compatibility

In the rest of this section, we use the $\mathtt{widthV}$ example from Section 3 to motivate the technical development of the migration type system and investigate the properties of the type system. The motivating goal is to type the condition $\mathtt{fixed}$ and the application $\mathtt{widthFunc 5}$ in $\mathtt{widthV}$ .

According to the annotation of $\mathtt{widthV}$ , the parameter $\mathtt{fixed}$ has type . Since $\mathtt{fixed}$ is used as a condition, it should have type $\mathtt{Bool}$ . Since both alternatives of the choice are consistent with $\mathtt{Bool}$ , this use should be considered well-typed. The variable $\mathtt{widthFunc}$ has type , which can be considered equivalent to . (In Section 4.4, we show how to achieve this formally with dom and cod.) The constant $\mathtt{5}$ has type $\mathtt{Int}$ . Since both alternatives of are consistent with $\mathtt{Int}$ , $\mathtt{widthFunc\,5}$ should also be considered well-typed.

These two examples demonstrate that we need a notion of compatibility between two migrational types to express that all of their variants are consistent. Intuitively, the compatibility relation incorporates both type equivalence for variational types (Chen et al., Reference Chen, Erwig and Walkingshaw2014) and type consistency for gradual types (Siek & Taha Reference Siek and Taha2006). The definition of compatibility ( $M_1\approx M_2$ ) is given in Figure 8. The relation is reflexive (MT-Refl) and symmetric (MT-Sym). The relation is transitive (MT-VtTrans) in the case that no $\star$ s are present, which we indicate by using the metavariable for variational types (V).

Figure 8. Rules defining type compatibility.

The rules MT-Idemp and MT-DeadElim specify compatibility under choice type simplification. Rule MT-Idemp states that a choice with identical alternatives is compatible with its alternatives. Rule MT-DeadElim says that two types are compatible under elimination of dead alternatives. Note that the operation $\lfloor M_1 \rfloor_{d.1}$ in the first alternative of d replaces each occurrence of a d choice in $M_1$ with its first alternative and thus removes the second alternative, which is unreachable due to choice synchronization. For example, , since $\mathtt{Bool}$ is unreachable in because selection with either A.1 or A.2 yields $\mathtt{Int}$ . A corresponding relationship holds for $\lfloor M_2\rfloor_{d.2}$ .

The rule MT-Cong defines that compatibility is a congruence relation. This rule allows us to replace a type $M_1$ in a context M[] with a compatible type $M_2$ . For example, since , we have if we view as the context. Finally, the rule MT-DynIntro states that if two types are compatible, replacing part of one type with $\star$ preserves compatibility. This rule is correct because $\star$ is compatible with anything. By choosing M to be an empty context, this rule encodes $M\approx\star$ and thus $\star\approx M$ through MT-Sym.

To illustrate compatibility, we show . This should hold, since both choice types only produce $\mathtt{Int}$ or $\star$ , which are consistent with each other and themselves. We can start by via MT-Idemp and via MT-Idemp and MT-Sym. We can then use MT-VtTrans to derive . After that, we can apply MT-DynIntro to replace the first $\mathtt{Int}$ in B with a $\star$ , apply MT-Sym, and apply another MT-DynIntro to replace the second $\mathtt{Int}$ in the choice A with a $\star$ , yielding . By applying MT-Sym one more time, we can derive the original goal.

With $\approx$ , we can formalize the application rule as follows.

Based on this rule and $\approx$ , we can calculate the type for $\mathtt{widthFunc 5}$ .

We demonstrate the correctness of $\approx$ by establishing its connection with type equivalence ( $\equiv$ ) from Chen et al., (Reference Chen, Erwig and Walkingshaw2014) and type consistency ( $\sim$ ) from Siek & Taha (Reference Siek and Taha2006) through the following theorems. In the theorems, we write $\lfloor M \rfloor_{\delta}\in V$ and $\lfloor M \rfloor_{\delta}\in G$ to denote that $\lfloor M \rfloor_{\delta}$ yields a variational type (no $\star$ ) and a gradual type (no variations), respectively. The first two theorems state the soundness of $\approx$ ; the third theorem states its completeness.

4.3 Pattern-constrained judgments

The goal in this subsection is to type the application $\mathtt{widthFunc fixed}$ in $\mathtt{widthV}$ , thus solving challenge C2 (error tolerance) for migrational typing. According to the type annotation of $\mathtt{widthV}$ , $\mathtt{widthFunc}$ has type , and $\mathtt{fixed}$ has type . Since it is impossible to derive (where the former is the domain of the function type and the latter is the type of the argument), the application rule from Section 4.2 fails to assign a type to $\mathtt{widthFunc fixed}$ . If we terminate the typing process, we will not be able to compute any type for $\mathtt{widthV}$ , failing to provide support for program migration.

While the compatibility check between and fails, we observe that $\star$ , the first alternative of A, is compatible with and $\mathtt{Int}$ , the second alternative of A, is compatible with $\star$ , the first alternative of B. This suggests that we should describe compatibility at a more fine-grained level than simply saying whether or not two migrational types are compatible. We employ the idea of typing patterns ( ${\pi}$ ) (Chen et al., Reference Chen, Erwig and Walkingshaw2012) to formalize this idea (see Figure 9). The patterns T and $\perp$ denote that the compatibility check succeeds and fails, respectively, and the choice pattern describes the success or failure of compatibility checking within the context of choice d.

Figure 9. Patterns and pattern-constrained relations and operations.. op can be any unary or binary operation on types. The is defined stipulations in the premise mean that the operations are defined on their input types, as specified in Figure 4. The is defined in the conclusion indicates that the operation can be safely carried out on the migrational type when constricted by ${\pi}$ .

In Figure 9, we also define selection on patterns, which is similar to selection on types ( $\lfloor V \rfloor_{\delta}$ ) in Figure 5. On page 13, we gave a detailed explanation on selection on types, and we skip the explanation of selection on patterns here.

We can now express the partial compatibility between and by the typing pattern . It is also possible to give some pattern that has an identical effect, such as the pattern .

In Figure 9, we define $M_1 \approx_{\pi} M_2$ such that $M_1$ and $M_2$ are compatible for all variants of ${\pi}$ that are T. In contrast, there is no requirement between $M_1$ and $M_2$ at other places. For example, , since $\mathtt{Int}\approx\mathtt{Int}$ at A.2 (and since we do not care that $\mathtt{Int}$ and $\mathtt{Bool}$ are incompatible at A.1).

The idea of constraining compatibility with patterns is quite powerful. We can even generalize it to typing judgments. Specifically, the typing relation $\pi$ ; $\Gamma \vdash e:M$ holds if $\lfloor \Gamma \rfloor_{\delta} \vdash \lfloor e \rfloor_{\delta}: \lfloor M \rfloor_{\delta}$ for all $\delta$ such that $\lfloor \pi \rfloor_{\delta}=T$ . The advantage is that we do not need to worry about the typing in variants where ${\pi}$ has $\perp$ s. That also means that we should not use (or trust) the typing result at variants where ${\pi}$ has $\perp$ s. We formally define this relation in Figure 9. For example, since $\Gamma \vdash \mathtt{1}:\mathtt{Int}$ we have , even though $\mathtt{Int}$ does not have the type $\mathtt{Int}$ . We can also generalize this idea to other operations, such as dom and cod, again defined in Figure 9.

As shown in the rule PatUnary, we can also use patterns to constrain unary functions so that they need to be defined for where only the pattern have $\top$ . In the rule, op could be instantiated to any unary functions, such as dom and cod. We use the following function dom to illustrate this idea.

The function dom is defined for three cases and is undefined for all other inputs. For example $dom(\mathtt{Int}\to\mathtt{Bool})=\mathtt{Int}$ but $dom(\mathtt{Int})$ is undefined. How about ? We can observe that it is defined for the first alternative but not the second alternative. In such case, we can constrain dom with a pattern to indicate that the function does not need to be defined for all alternatives of variations. For our example, we can use the pattern to convey that we only need the first alternative of A to be defined (because the pattern there is a $\top$ ) while ignore whether the second alternative is defined or not (because the pattern there is a $\perp$ ). With this idea, is defined in both alternatives of A. Moreover, for the second alternative, we can say the result dom is any type because $\perp$ in that alternative indicates that the typing result will be discarded. Only typing results in variants where typing pattern has $\top$ are valid and considered.

Similarly, we can define $cod_{\pi}$ if we have a function cod, which we define in Figure 10. The rule PatBinary allows us to constrain binary operations or functions in the same way.

Figure 10. Typing rules. The operations dom, cod, and $\sqcap$ are undefined for cases that are not listed here. The process for obtaining $dom_{\pi}$ from dom is detailed in Section 4.3. The operations $cod_{\pi}$ and $\sqcap_{\pi}$ can be obtained similarly through Figure 9.

Based on the idea of pattern-constrained judgments, we can define the following rule for typing function applications (where dom is defined above and cod will be defined in Figure 10):

With this new rule, which accounts for migrational types with type errors, we can revisit the problem of typing $\mathtt{widthFunc fixed}$ . Let . Since belongs to $\Gamma$ , we have $\pi;\Gamma\vdash\mathtt{widthFunc}:M$ , where . Similarly, we have . Next, . As we have seen earlier, . Thus, all the premises of the application rule are satisfied, and we can derive . Based on the result pattern, we should not trust the typing information at the variant $\{A.2,B.2\}$ since $\lfloor \pi \rfloor_{\{A.2,B.2\}}=\perp$ .

While pattern-constrained judgments simplify the presentation, we still face the challenge of finding appropriate patterns, which are inputs to the typing relation. However, the pattern is determined by the typing constraints among the subexpressions. For example, the type of the argument must match the argument type of the function. The reason we use in typing $\mathtt{widthFunc fixed}$ is that the application is ill-typed at $\{A.2,B.2\}$ . Therefore, in a language with type inference, the pattern will be computed during the inference process (Sections 6 and 7).

4.4 Typing rules

The typing rules are shown in Figure 10. They are based on the compatibility relation (Section 4.2) and pattern-constrained judgments (Section 4.3). The typing judgment has the form $\pi;\Gamma\vdash e:M|\Omega$ and expresses that e has type M under environment $\Gamma$ constrained by the pattern ${\pi}$ . The mapping ${\Omega}$ collects the types that will be assigned to parameters if their $\star$ s are removed. We assume that parameter names from different functions are uniquely identified in the domain of ${\Omega}$ . The goal of ${\Omega}$ is to connect the typing rules here with those from Figure 4. We discuss this aspect in more detail in Section 4.5 where we investigate the properties of the type system.

The rules for constants (Con) and variables (Var) are straightforward. They hold for arbitrary patterns ${\pi}$ because constants and bound variables are always well-typed. Moreover, since the types remain unchanged, ${\Omega}$ is always $\varnothing$ . The rule Abs for an abstraction whose parameter is not annotated with $\star$ is conventional. In rule Absdyn for an abstraction whose parameter is annotated with $\star$ , we assign the parameter a choice type where the first alternative is $\star$ implying that the $\star$ is kept and the second alternative can be any type for the body to be well-typed. As a result, when variations are first introduced, their first alternatives are $\star$ s. This change information is recorded by extending the ${\Omega}$ returned from typing the body of the abstraction.

The App rule for applications is similar to the one in Section 4.3 except that we must combine the variational statifiers from typing the two subexpressions. The operations $dom_{\pi}$ and $cod_{\pi}$ can be obtained from dom and cod respectively using the idea of pattern-constrained operations discussed in Section 4.3.

The rule If types conditionals; it relies on an extended version of the meet operation ( $\sqcap$ ) from Figure 4 that also handles choices. The definition $\sqcap_{\pi}$ can be obtained from Figure 9 by instantiating the op in rule ParBinary with $\sqcap$ . In Section 4.3, we gave a detailed example of deriving $dom_{\pi}$ from dom and $\sqcap_{\pi}$ can be derived from $\sqcap$ similarly.

The Weaken rule states that if a typing pattern can be used to derive a typing, then we can use a less-defined pattern to derive the same typing. The operation $=_{{\pi}_1}$ in the premise specifies that its arguments must be the same for places where $\pi_1$ has $\top$ s. A typing pattern $\pi_1$ is less defined than $\pi_2$ if it contains $\perp$ values at least everywhere $\pi_2$ does. The purpose of Weaken is to make the typing process compositional. Without this rule, the whole typing derivation must use the same ${\pi}$ . With this rule, we can use different patterns for typing the children of a construct but adjust them to use the same pattern when typing the construct itself. To illustrate, consider typing an application $e_1 e_2$ . It is likely that $e_1$ and $e_2$ will contain errors at different variants, and thus, the typing patterns for typing them will be different.ithout Weaken, we should use a single pattern for typing these two subexpressions. With Weaken, we can use different patterns for typing subexpressions, and before typing the application itself we can apply Weaken to the typing derivation for either or both $e_1$ and $e_2$ to make their patterns the same. After that, we can apply the App rule.

The less-defined relation on patterns, written as $\pi_1 \leq \pi_2$ , is formally defined in Figure 10. The rules Pat-Ok and Pat-Err define that any pattern is less defined than $\top$ and more defined than $\perp$ . The rule Pat-Trans defines that the relation is transitive. The last three rules handle variational patterns. The rule Pat-Sinchc states that a pattern is less defined than a variational pattern if it is less defined than both alternatives of the variational pattern. The rule Pat-Chcsin states that a variational pattern is less defined than a pattern if both alternatives are. Finally, the rule Pat-ChcChc says that two variational patterns satisfy the less-defined relation if their corresponding alternatives do.

4.5 Properties

This subsection investigates the properties of the type system. Since the goal of migrational typing in Figure 10 is to type all possible programs that remove $\star$ s for a given program at once, we want to investigate whether migrational typing does it currently for individual programs and whether it indeed types all programs that remove $\star$ s. To this end, we consider the relationship of the rules for migrational typing in Figure 10 and the original rules for gradual typing in Figure 4. We also consider the relation between different typing derivations $\pi;\Gamma\vdash e: M|\Omega$ when different ${\pi}$ s and Ms are used for the same $\Gamma$ and e, which addresses challenge C3 (best typing) from Section 3.

We start by introducing some notation. We say a decision $\delta$ is complete for an expression e if it contains d.1 or d.2 for each d created while typing e. For ${\pi}$ , a decision $\delta$ is complete if $\lfloor \pi \rfloor_{\delta}$ yields $\top$ or $\perp$ . Note that a complete decision for ${\pi}$ may not be complete for the expression since patterns compactly represent where typing succeeds and where it fails. For instance, while typing $\mathtt{rowAtI}$ , we created five choices A, B, D, E, and F for the dynamic parameters from left to right, respectively. Thus, each complete decision for $\mathtt{rowAtI}$ contains five selectors. One typing pattern for $\mathtt{rowAtI}$ is:

Both $\{A.1,E.1\}$ and $\{B.2,B.2\}$ are complete decisions for $\pi_a$ but not for $\mathtt{rowAtI}$ . In the case that the whole migration space for an expression is well-typed, then the pattern is simply $\top$ and the complete decision is. We use the notation $\delta|2$ to collect all of choice names d such that $d.2 \in \delta$ .

The notions of decisions ( $\delta$ ), variational statifier ( ${\Omega}$ ), and statifier ( ${\omega}$ ) are closely related. Specifically, during typing, for each dynamic parameter x, ${\Omega}$ includes a mapping $x\mapsto V$ , where V is the type that will be assigned to the parameter once its $\star$ annotation is removed. Therefore, given ${\Omega}$ and $\delta$ , we can generate a statifier as follows, where chc(x) returns the name of the choice created for x.

\begin{equation*}statifierForDesc(\Omega,\delta)=\{x\mapsto\lfloor V \rfloor_{\delta}|x\mapsto V\in\Omega \wedge chc(x)\in\delta|2\}\end{equation*}

For example, let

\begin{equation*}\Omega_{a}=\{\mathtt{fixed}\mapsto\mathtt{Bool},\mathtt{widthFunc}\mapsto\mathtt{Int}\to\mathtt{Int}\}\qquad\delta_{a}=\{A.2,B.1\}\end{equation*}

then $statifierForDesc(\Omega_{a},\delta_{a})$ .

The notation $G_1\sqsubseteq G_2$ means that $G_2$ is more static than $G_1$ ; it is defined as follows.

We further say that $G_2$ is better than $G_1$ , written as $G_1\preceq G_2$ , if $G_1\sqsubseteq G_2$ or $G_1 = \theta_2(G_2)$ for some $\theta_2$ . Intuitively, $G_1\preceq G_2$ if $G_2$ is equally or more static than $G_1$ or they are equally static and for any static part in $G_1$ , $G_2$ has the same static type or a type variable. For example, we have $\star\to\alpha\preceq\mathtt{Int}\to\mathtt{Int}$ and $\mathtt{Int}\to\mathtt{Int}\preceq\mathtt{Int}\to\alpha$ .

We next demonstrate the correctness of our type system by showing that, at the places where the typing pattern is valid, it assigns the same types to all the programs in the migration space as the brute-force approach does.

This theorem states that, for any removal of $\star$ annotations, the typing result encoded in migrational typing is the same as by typing the program with ITGL. For example, for we get $\pi_{a}^{\prime};\Gamma\vdash\mathtt{width}:M_{a}|\Omega_{a}$ , where and $\Omega_{a}$ is as defined earlier. We can verify $statifierForDesc(\Omega_{a},\delta_{a});\Gamma\vdash_{GC}\mathtt{width}:\mathtt{Bool}\to\star\to\star$ and $\lfloor M_{a} \rfloor_{\delta_{a}}=\mathtt{Bool}\to\star\to\star$ , where $\delta_{a}$ is as defined earlier.

Conversely, any removal of $\star$ that yields a well-typed program is encoded in some typing derivation in migrational typing, as expressed in the following theorem.

We can observe that for a given expression, there may be multiple typing derivations based on the typing rules in Figure 10. The reason is that, for example, the variational types used for typing the same Absdyn in different typings could be different. Particularly, we want to know if there exists a best typing derivation that is more static and more defined (the corresponding typing pattern contains $\perp$ in fewest variants) than all other derivations. Fortunately, this is indeed the case (Lemma 2). We next investigate the relation between different typings. In Lemma 1, we will show that different typings can be combined to make the result as correct as possible (that is, to minimize $\perp$ s in the result pattern). In Lemma 2, we show different typing can be combined to be made as good as possible (that is, to make types more static and more general). Note that the typing process records all dynamic parameters and corresponding variational types in ${\Omega}$ . As a result, the domain of ${\Omega}$ s in different typings are the same. However, the ranges could be different because different typings may use different Vs in Absdyn.

The following lemma states that we can always find a better (in the sense of the better relation defined at the beginning of this section, in Page 24) variational statifier and typing for any expression.

The properties captured by the previous two lemmas can be combined to show that for any expression there exists a typing that has the most defined pattern and the most static and general result type. We refer to this typing as the most general static migrational typing, abbreviated as the MGSM typing.

To illustrate the use of Theorem 6, the MGSM typing for $\mathtt{width}$ is $\pi_{b};\Gamma\vdash\mathtt{width}:M_{b}$ , where

Theorem 6 implies that while an infinite number of typings may be derived (due to the $\perp$ pattern), we need only care about the MGSM typing since it encodes all the typings for the whole migration space. Sections 6 and 7 investigate the problem of computing the MGSM typing.

5.1 Relationships between migrations

Since every migration can be identified by an eliminator for the MGSM typing, and since stricter eliminators correspond to more static migrations, the problem of computing the most static migrations can be reduced to the problem of finding the strictest valid eliminators.

Instead of considering all valid eliminators for an expression (which is exponential in the number of dynamic parameters), we instead consider the valid eliminators of the typing pattern for the MGSM typing of the expression. The reason is that typing patterns are usually small, yielding fewer eliminators that we have to consider (in fact, later results will show that we do not have to consider even all of these). For example, the pattern $\pi_a$ from Section 4.5 for $\mathtt{rowAtI}$ has only 5 eliminators while the expression itself has 32. As another example, from the pattern $\pi_{b}$ , defined at the end of Section 4.5 (page 25), we can see that $\delta_{ab}^{v}=\{A.1\}$ compactly represents $\delta_{a}^{v}$ and $\delta_{b}^{v}$ for $\mathtt{width}$ .

Our first question is whether any eliminator that is stricter than an invalid eliminator could be valid. This question seems irrelevant for this example because the invalid eliminator $\delta_{d}$ is already the strictest for $\pi_{b}$ . However, this is not the case in general, and knowing the answer to this question helps us to prune the search space. For example, the eliminator $\{A.1,B.1,E.2\}$ is invalid for $\pi_{a}$ , and we want to know whether any of the stricter eliminators— $\{A.1,B.2,E.2\}$ , $\{A.2,B.1,E.2\}$ and $\{A.2,B.2,E.2\}$ —are valid. The following theorem answers this question.

This theorem implies that we can simply ignore invalid eliminators and focus on valid ones, since all invalid eliminators lead to ill-typed expressions.

A valid eliminator for the typing pattern corresponds to potentially many valid eliminators for the expression. We say that a valid pattern eliminator $\delta_{1}$ covers a valid expression eliminator $\delta_{2}$ if $\delta_{1}\subseteq\delta_{2}$ . Among all the expression eliminators covered by a pattern eliminator, one is strictest. For example, the eliminator $\delta_{ab}^{v}$ for pattern $\pi_{b}$ covers the eliminators $\delta_{a}^{v}$ and $\delta_{b}^{v}$ for typing $\mathtt{width}$ , and $\delta_{b}^{v}$ is the strictest. As another example, the valid eliminator $\delta_{ae}^{v}=\{A.1,E.1\}$ for pattern $\pi_{a}$ covers eight valid eliminators (two options for each of the three choice names that do not appear in the pattern) for typing $\mathtt{rowAtI}$ , and $\{A.1,E.1,B.2,D.2,F.2\}$ is the strictest among them.

Among all expression eliminators covered by a pattern eliminator, stricter ones yield better result types. This is expressed by the following theorem.

As an example illustrating Theorem 8, consider $\delta_{a}^{v}$ , $\delta_{b}^{v}$ , and $M_b$ , introduced in Section 4.5. We can verify that both $\delta_{a}^{v}\gg\delta_{b}^{v}$ and $\lfloor M_{b}\rfloor_{\delta_{a}^{v}}\preceq\lfloor M_{b}\rfloor_{\delta_{b}^{v}}$ , where $\lfloor M_{b}\rfloor_{\delta_{a}^{v}}=\star\to\star\to\star$ , and $\lfloor M_{b}\rfloor_{\delta_{b}^{v}}=\mathtt{Bool}\to\star\to\star$ .

Theorem 8 provides a way to order the eliminators covered by a single pattern eliminator, but how about ordering different valid eliminators of the typing pattern? Considering pattern $\pi_b$ , neither of the valid eliminators $\delta_{b}^{v}$ or $\delta_{c}^{v}$ is stricter than the other. Similarly, for pattern $\pi_a$ , neither of the valid eliminators is stricter than the other. In fact, this property holds not only for these two examples but also for a class of typing patterns that are in pattern normal form. We say a pattern is in normal form if it does not contain idempotent choices (choices with identical alternatives) and does not nest a choice in another choice with the same name (no dead alternatives). We capture this property in the following theorem.

• • $\delta_{1}^{v}=\{d_{1}.1,d_2.1\}$ and $\delta_{2}^{v}=\{d_{1}.1,d_2.1\}$ or $\{d_{1}.2,d_{2}.2\}$ . Based on $\delta_{2}^{v}$ , $\delta_{3}^{v}=\{d_{1}.1,d_{2}.2\}$ is a valid eliminator based on the inverse of the implication in Theorem 7. From $\delta_{1}^{v}$ and $\delta_{3}^{v}$ , we can infer that both alternatives of $d_2$ are $\top$ , meaning that it is an idempotent variation and ${\pi}$ is not in normal form.

• • $\delta_{1}^{v}=\{d_{1}.1,d_2.1\},\{D_{1}.2,d_{2}.1\}$ or $\{d_{1}.2,d_{2}.2\}$ . The reasoning is similar to the previous case by showing that the variation $d_2$ is idempotent.

• • $\delta_{1}^{v}=\{d_{1}.1\}$ and $\delta_{2}^{v}=\{d_{1}.2,d_{2}.1\}$ . The decision $\delta=\{d_{1}.2,d_{2}.2\}$ satisfies $\delta_{1}^{v}\gg\delta\wedge\delta_{2}^{v}\gg\delta$ . If $\delta$ is a valid eliminator, then we can again show that $d_2$ is idempotent, a contradiction that ${\pi}$ is in normal form.

We could swap the assignments to $\delta_{1}^{v}$ and $\delta_{2}^{v}$ , but this will yield the same proof result.

It follows from the theorem that for any two valid eliminators $\delta_{1}^{v}$ and $\delta_{2}^{v}$ for $\pi_1$ , $\delta_{1}^{v}\gg\delta_{2}^{v}$ and $\delta_{2}^{v}\gg\delta_{1}^{v}$ . Two eliminators that are incomparable with respect to $\gg$ will remove $\star$ s for different parameters for the same expression, leading to types that are incomparable by $\sqsubseteq$ (defined in Section 4), and thus incomparable by $\preceq$ . For example, since $\delta_{b}^{v}\gg\delta_{c}^{v}$ and $\delta_{c}^{v}\gg\delta_{b}^{v}$ , we have $G_{b}\preceq G_{c}$ and $G_{c}\preceq G_{b}$ , where $G_{b}=\lfloor M_{b}\rfloor_{\delta_{b}^{v}}=\star\to(\mathtt{Int}\to\beta)\to\beta$ and $G_{c}=\lfloor M_{b}\rfloor_{\delta_{c}^{v}}=\mathtt{Bool}\to\star\to\star$ .

Combining Theorems 8 and 9 yields the following result about finding most static migrations. We develop an algorithm for extracting such migrations in Section 5.2.

It follows from the theorem that e has a unique most static migration if $\pi_1$ has only one valid eliminator.

5.2 Extracting most static migrations

The most static migrations for a program are identified by valid eliminators that describe whether to pick the $\star$ annotation or the inferred type for each parameter. We compute this set of eliminators from an MGSM typing in three steps: (1) simplify the typing pattern to its normal form, (2) collect the valid eliminators for the normal form, and (3) expand each valid eliminator into a strictest eliminator for the corresponding expression.

Simplifying a typing pattern to its normal form has two advantages. First, the valid eliminators are fewer and smaller. Second, we can use the result of Theorem 10 to find most static migrations. We use the following rules to simplify patterns to normal forms.

The first two rules remove idempotent choices and dead alternatives. The third rule enables simplifying parts of a larger pattern. For example, we can use the third and the first rule to simplify the pattern to pattern $\pi_a$ from Section 4.5.

We use the function $(\pi)$ to build the set of valid eliminators for a pattern ${\pi}$ in normal form.

To illustrate the definition of ve, we consider the calculation process for the pattern . . This means that the set of valid eliminators for contains only one element: $\{A.1\}$ . Similarly, . As another example, $ve(\pi_a)$ yields $\{\delta_{o}^{v},\delta_{p}^{v}\}$ , where $\delta_{o}^{v}=\{A.1,E.1\}$ and $\delta_{p}^{v}=\{A.2,B.1,E.1\}$ .

Finally, we use the following function $expand(\delta,\mathscr{D})$ to compute the strictest expression eliminator from the given pattern eliminator $\delta$ and the set $\mathscr{D}$ of all choice names in the expression.

\begin{equation*}expand(\delta,\mathscr{d})=\delta\cup\{d.2|d\in\mathscr{D}\wedge d.1\in\delta\}\end{equation*}

For example, the set of choice names $\mathscr{D}$ for typing $\mathtt{rowAtI}$ is $\{A,B,D,E,F\}$ , and $expand(\delta_{o}^{v},\mathscr{D})$ yields $\{A.1,E.1,B.2,D.2,F.2\}$ and $expand(\delta_{p}^{v},\mathscr{D})$ yields $\{A.2,B.1,E.1,D.2,F.2\}$ .

Each expanded valid eliminator is a best eliminator that specifies how to migrate the program. For example, the first best eliminator for $\mathtt{rowAtI}$ above removes the $\star$ annotation for $\mathtt{widthFunc}$ , $\mathtt{table}$ , and $\mathtt{i}$ , while the other best eliminator removes the $\star$ annotation for $\mathtt{fixed}$ , $\mathtt{table}$ , and $\mathtt{i}$ .

Formally, given an expression e and its MGSM typing $\pi;\Gamma\vdash e:M||\Omega$ , then for any expanded valid eliminator $\delta^{v}$ , we can generate the most static migration using $statifierForDesc(\Omega,\delta^{v})$ , defined in Page 23.

Overall, these three steps provide a simple way to extract the most static migration from an MGSM typing. In Section 10, we show that these steps lead to an efficient implementation. Usually, the normal form of a typing pattern is small and has only a few valid eliminators. For example, if the program is still well-typed after removing all $\star$ annotations, then the pattern will be $\top$ , which has only one valid eliminator (the empty set). Similarly, if the program is ill-typed if any $\star$ annotation is removed, then there is again just one valid eliminator.

Since normal forms are ideal, we will show in Section 7 how we can efficiently maintain patterns to be in normal form throughout the type inference process.

7.1 Solving compatibility constraints

We first motivate the structure and design of the algorithm with the following examples. ()

1. (i) $\alpha\approx^{?}\star\to\mathtt{Int}$

2. (ii)

Our solver must adhere to certain rules to ensure the correctness of type inference, including:

1. I. $\star$ is compatible with any type (Section 2.1).

2. II. Type variables are only substituted by static types (Section 4).

3. III. The typing pattern produced must be as defined as possible (Section 4).

Problem (i) helps illustrate rule (II). Intuitively, $\alpha$ should be substituted by a function type whose codomain is $\mathtt{Int}$ , but what should the domain be? Essentially, the domain should be an unconstrained type variable so that it can unify with a static type later, if necessary. As a result, we generate the substitutions $\{\kappa_{2}\mapsto\mathtt{Int}\}\circ\{\alpha\mapsto\kappa_{1}\to\kappa_{2}\}$ . Since $\kappa_1$ is a fresh type variable that is not mapped to anything, it is unconstrained. In contrast, $\kappa_2$ is mapped to $\mathtt{Int}$ . This substitution satisfies both rules (I) and (II).

Problem (ii) demonstrates the need for error tolerance in solving constraints. The natural way to solve a choice constraint is to decompose it into two constraints. Doing this on constraint (ii) yields two subconstraints, $\star\approx^{?}\mathtt{Int}$ and $\mathtt{Bool}\approx^{?}\mathtt{Int}$ , where . According to rule (I), the first constraint is solved successfully and $\pi_1$ is updated to $\top$ . The second constraint, however, fails to solve, since $\mathtt{Bool}$ cannot be made compatible with $\mathtt{Int}$ , so we update $\pi$ to $\perp$ . Consequently, we update ${\pi}$ to to reflect that constraint solving fails in A.2. Choosing instead $\perp$ for ${\pi}$ would yield a consistent result but would violate rule (III).

7.2 A unification algorithm

Figure 13 presents a unification algorithm $\mathscr{U}$ , which takes a constraint and produces a substitution $\theta$ and a pattern ${\pi}$ . The algorithm can be understood as extending Robinson’s unification algorithm (Robinson Reference Robinson1965) to handle variational types and dynamic types and to support error tolerance. To support error tolerance, the unification not only returns a substitution but also a typing pattern. The unification is successful at variants where the pattern has $\top$ and is failed at variants where the pattern has $\perp$ . In the algorithm, cases (a) and (a*) deal with dynamic types, cases (c), (d), and (d*) deal with variations. Cases (g) through (j) deal with non-compatibility constraints. Other cases of the algorithm resemble their counterparts in Robinson’s algorithm but still need to account for occurrences of $\star$ s and variations.

Figure 13. A unification algorithm.

In the figure, we use the following conventions and helper functions. We use $\kappa$ s to denote fresh type variables. The function choices(M) returns the set of choice names in M; vars(M) returns the set of type variables in V. The predicate hasDyn(M) determines whether $\star$ occurs anywhere in M. The function merge combines the substitutions from solving the subproblems of a choice constraint. For example, given d, $\theta_1=\{\alpha\mapsto\mathtt{Int}\}$ , and $\theta_{2}=\{\alpha\mapsto\mathtt{Int}\}$ , we have . Formally, the definition of merge (for each $\alpha$ in $\theta_1 \cup \theta_2$ ) is:

Intuitively, if $\alpha\in dom(\theta)$ , then $get(\alpha,\theta)$ returns the image of $\alpha$ in $\theta$ . Otherwise, $get(\alpha,\theta)$ returns a fresh type variable. Recall that $\kappa$ denotes a fresh type variable.

We now briefly walk through each case of $\mathscr{U}$ . Some cases of $\mathscr{U}$ have dual cases, and names of such cases differ by a $\star$ . Essentially, the starred version delegates the real solving task to the case without a $\star$ . Case (a) handles the trivial constraints involving $\star$ . Such constraints are simply discarded without generating any mapping. We return $\top$ as the pattern, since $\star$ is compatible with any type. More importantly for $\alpha\approx^{?}\star$ , case (a) takes priority over (b), ensuring that the substitution $\{\alpha\mapsto\star\}$ is not generated.

Case (b) unifies a type variable $\alpha$ with a migrational type M. This case includes many subcases. First, if M does not contain $\star$ and $\alpha$ does not occur in M, then $\alpha$ is directly mapped to M. For example, given , the substitution is returned, and ${\pi}$ is updated to $\top$ . Second, if M contains variation, the result is computed via case (d). For example, the problem is transformed into .

Next, if M is a function type that contains $\star$ and $\alpha$ does not occur in M, then we transform $\alpha$ into a function type by using fresh type variables and delegate the solving to case (f). The problem (i) in Section 7.1 falls in this case. This case essentially solves two constraints, and we will have two typing patterns ( $\pi_{1}$ and $\pi_{2}$ in the algorithm). We need to combine them into one. The resulting pattern must be restricted enough to create a valid solving result but well defined enough to give useful information about where constraint solving succeeds. The operation $\sqcap$ , can be viewed as a meet operation over the less defined partial order on typing patterns in Figure 10. It creates the greatest lower bound of two patterns, ensuring that the most defined pattern is used for solving the constraint.

Back to case (b), if all previous subcases fail, $\perp$ is returned, indicating that the constraint failed to solve.

Case (c) handles constraints involving two choice types that share an outer choice name. It decomposes the constraint into two smaller problems and solves them individually. For instance, consider the constraint . This constraint will be decomposed into $\star\approx^{?}\mathtt{Int}$ and $\alpha\approx^{?}\mathtt{Bool}$ , which will be solved by (a) and (b), respectively. Case (d) unifies a choice type with another type not handled by case (c). This case employs a similar implementation idea as case (c) does. For example, for , the two smaller constraints to be solved are $\star\approx^{?}\mathtt{Int}$ and $\mathtt{Int}\approx^{?}\mathtt{Int}$ . Case (e) unifies two static types and is delegated to Robinson’s unification algorithm (Robinson Reference Robinson1965). Case (f) unifies two function types by unifying their respective argument and return types. Cases (g), (h), (i), and (j) deal with non-compatibility constraints.

To keep patterns in normal form, we also perform the following optimizations to prevent idempotent choices patterns from being created. In cases (c) and (f), when creating the choice pattern , we check if $\pi_1$ and $\pi_2$ are the same; if so, the choice pattern is replaced by $\pi_1$ . In the last two cases of $\sqcap$ in Section 6, we perform the same optimization. After this, the algorithm maintains patterns in normal forms, since the generated constraints do not contain dead alternatives and since the case (d) of $\mathscr{U}$ prevents dead alternatives from being introduced.

Unification examples In Section 6, we generated two constraints for the expressions $\lambda x:\star.\mathtt{succ}(x \mathtt{True})$ and $\lambda x:\star.x(\mathtt{Succ}(x \mathtt{True}))$ . We use these two constraints to illustrate the unification process.

The first constraint is . For this constraint, case (h) applies, which breaks the variational constraint into two smaller constraints in each alternative and then combine the results from alternatives. The left alternative has the constraint $\varepsilon$ , which will be solved by case (g) with the solution $(\theta_{l},\top)$ , where $\theta_{l}=\varnothing$ . The right alternative has the constraint $C_1 \wedge C_2 \wedge C_4$ . We will repeatedly use case (i) to handle each subconstraint $C_1$ through $C_4$ . Since there are no $\star$ s and variations in these constraints, they degenerate to conventional type equality constraints. We can use Robinson’s unification algorithm to solve them. The unifier is

\begin{equation*}\theta_{r}=\{\alpha\mapsto\mathtt{Bool}\to\mathtt{Int},\kappa_{1}\mapsto\mathtt{Bool},\kappa_{2}\mapsto\mathtt{Int},\kappa_{4}\mapsto\mathtt{Int}\}\end{equation*}

The typing pattern for solving them is $\top$ as the solving for each constraint returns $\top$ .

After we have the solutions for both alternatives, we will now combine them together. First, the combined typing pattern is , which simplifies to $\top$ , meaning that the type inference succeeds everywhere. Next, we combine unifiers with the function merge defined earlier in this subsection. Note, since $\theta_{l}$ is $\varnothing$ , the second case of merge will handle each mapping in $\theta_{r}$ . For example, as $\alpha\mapsto\mathtt{Bool}\to\mathtt{Int}\in\theta_{r}$ , then the merged substitution includes , where $\kappa_8$ is s fresh type variable. Here we use a fresh type variable in the first alternative to denote that the first alternative for $\alpha$ is not constrained yet, allowing future unification with any type, if necessary. Overall, let $\theta_m$ be the substitution after merging $\theta_l$ and $\theta_{r}$ , then

Substituting the result type with $\theta_m$ yields the type , which simplifies to the type after we eliminate the unreachable alternative $\kappa_8$ . Since the combined typing pattern is $\top$ and selecting $\top$ with $\{A.2\}$ yields $\top$ , it means that we can migrate x, the parameter associated with the choice A. Moreover, based on the result type of , we know the migrated expression has the type $(\mathtt{Bool}\to\mathtt{Int})\to\mathtt{Int}$ .

Now we solve the constraint generated for the expression $\lambda x:\star.x(\mathtt{succ}(x\mathtt{True}))$ . We proceed similarly as before. In particular, constraint solving $C_1$ through $C_4$ yields the unifier $\theta_{r}$ mentioned above. We then need to solve $C_5$ and $C_6$ from $\theta_r$ . When solving $C_6$ , we need to unify $\mathtt{Bool}\to\mathtt{Int}$ with $\mathtt{Int}\to\kappa_{8}$ , which fails. The pattern returned is thus $\perp$ . Therefore, the pattern for solving the whole constraint is . Based on the pattern, we know that we cannot migrate x.

Note, even though our approach cannot migrate x, types more precise than $\star$ could actually be assigned to x, such as $\star\to\mathtt{Int}$ . The reason we cannot find this migration is that $\lambda x.x(\mathtt{succ}(x\mathtt{True}))$ is not well-typed under type inference by Garcia & Cimini (Reference Garcia and Cimini2015), and our type inference can be considered as the variational version of theirs. We provide an extension to the unification algorithm $\mathscr{U}$ to infer more precise types in Section 9.2.

7.3 Properties

We now investigate the properties of $\mathscr{U}$ . First, $\mathscr{U}$ is terminating.

Next, we show that $\mathscr{U}$ is correct by showing that it is both sound and complete. For simplicity, we state the result for constraints of the form $M_{1}\approx^{?}M_{2}$ only. In fact, we can transform other forms into this form. For example, can be transformed into Note that ${\pi}$ in the constraint is just a placeholder and will be updated when the constraint solving finishes.

The idea of the proof is to go through all possible constructs of the type M and show that $\mathscr{U}$ covers all possibilities. To establish that most general unifiers exist, we get the results directly from the induction hypothesis (and compose the mgus of the subterms) or use proof by contradiction. As the proof is standard and lengthy, we omit it here.

8.1 Duality to removing dynamism

The program $\mathtt{rowAtISt}$ can be thought of as one of the programs in the migration space of $\mathtt{rowAtI}$ in Figure 1. In fact, it is the bottom-most program in the figure had we listed out the full migration space there. Recall that programs 3 and 5 were the most static migrations for program 1. While introducing $\star$ s for $\mathtt{rowAtISt}$ , programs 3 and 5 are likewise the programs we desire since they keep as many static types as possible and are still well-typed.

We can envision organizing the whole migration space into a lattice where more dynamic programs are in the upper portions of the lattice (Takikawa et al., Reference Takikawa, Feltey, Greenman, New, Vitek and Felleisen2016). The process of removing dynamism to make the program static keeps going down the lattice before a type error appears. The process of introducing dynamism to fix type errors keeps going up the lattice until type errors disappear. Overall, these two processes are dual. This fact inspires our formal development to realize the process of introducing dynamism, which we shall see next.

Typing rules. In removing dynamism, we introduce variations for parameters whose type annotations are $\star$ s and not to others. Based on the duality, we should now introduce variations to parameters without $\star$ annotations and not to others. Specifically, we define a new type system using the judgment form $\pi;\Gamma\vdash_{D} e:M|\Omega$ . This judgment has the same meaning as the one in Figure 10 and shares the same rules as that one except for Abs and Absdyn, for which typing rules are as follows.

These two rules are dual to the corresponding ones in Figure 10. For an abstraction with a static type, the type error may be removed by changing its parameter to have the dynamic type. We express this by creating a fresh variation with its first alternative being $\star$ , as can be seen in the Abs rule. The rule then records the changes in the variational statifier. For Absdyn, no changes will be made for the parameter type, and thus no variations are created in the rule, since our goal is to fix static type errors and not to migrate programs towards using more static typing.

Using the given typing rules, we can derive the following type for $\mathtt{rowAtISt}$ , assuming the variation names for parameters from left to right are A, B, D, E, F, G.

The typing pattern for it is:

Connection to ITGL. Each variational statifier (in this context perhaps it should be renamed to dynamifier) generated by the $\vdash_{D}$ type system now collects parameters for which $\star$ annotations are added (instead of removed as was done previously). From the variational statifier, we can generate a statifier for each given decision as follows.

\begin{equation*}\Omega[\delta]=\{x\mapsto\lfloor M\rfloor_{\delta}|x\mapsto M\in\Omega\}\end{equation*}

The generated statifier coerces certain parameters to have type $\star$ s and leaves others to their original types. We can define a type system similar to the type system in Figure 4 that types gradual expressions under updates from statifiers. The new type system is the same as the one in Figure 4 except for the rules Abs and Absdyn, which are presented below.

In Abs, a parameter with a static type is maybe assigned a $\star$ if the ${\omega}$ specifies so. For functions with $\star$ parameters, handled by Absdyn, the typing rule does not update their types.

Finding error fixes. The $\vdash_{D}$ typing relation indeed finds correct and complete fixes to type errors, as captured in the following theorems, which serve a similar goal as Theorems 4 through 6 served in the type system of removing dynamism. The proofs of these theorems thus follow those closely and are omitted here.

The previous theorem indicates that we can use migrational typing to fix errors but does not state that the fixes are minimal. The following theorem states that we can find a most general, least dynamic fix for a program. We call this the MGDM typing.

From the typing pattern ${\pi}$ in MGDM, we can reuse the machinery to find the best migration in Section 5.2 for finding migrations that fix type errors by introducing fewest $\star$ s to parameters. For example, the ${\pi}$ for the MGDM of $\mathtt{rowAtISt}$ is ${\pi}_d$ given earlier. This pattern indicates that either $\mathtt{fixed}$ and $\mathtt{border}$ should have $\star$ s to remove the type error, or $\mathtt{widthFunc}$ and $\mathtt{border}$ should have $\star$ s.

8.2 Discussion

This section demonstrates that migrational typing is flexible and can be easily adapted to solve another interesting program migration problem. The fundamental reason is that migrational typing provides an efficient method to explore the typing of the full migration space and extract the desired migrations from that space, which naturally lends itself to solving other migration problems.

It is interesting to see if we can fix type errors and migrate programs to utilizing more static typing simultaneously. Essentially, such a process first adds $\star$ annotations to remove the type error and then inspects to see if other $\star$ annotations can be safely removed after the error is fixed. Note that typing rules in Figure 10 introduce variations for parameters with $\star$ s and those in this section introduce variations for parameters that have no $\star$ s. This suggests that the type system that simultaneously fixes type errors and migrates programs should create variations for all parameters. Specifically, the Absdyn rule should be the same as the one in Figure 10 while Abs be the same to the one in $\vdash_D$ . After that, we can use the method descried in Section 5.2 to extract the migration that removes type errors as well as migrate the program to be as static as possible.

The simplicity of the type system for this purpose echoes our early observation about the flexibility and adaptability of migrational typing.

9.1 Other language features

Our version of ITGL, given in Figure 10, restricts parameters to be either unannotated or annotated by $\star$ . The formulation of gradual typing by Garcia & Cimini (Reference Garcia and Cimini2015) allows arbitrary gradual type annotations on parameters and also supports type ascription, that is, asserting by $e::G$ that expression e has type G.

We can extend our type system to support arbitrary gradual type annotations as follows. Given an abstraction $\lambda x:G.e$ , if $G=\star$ or G is fully static, type the abstraction as usual; if G is a complex type containing $\star$ types, replace G by a choice whose first alternative is G and whose second alternative replaces all dynamic parts by arbitrary types. For example, if $G=\mathtt{Int}\to\star\to\star$ , then the type of the parameter is , where d is fresh. To generate the corresponding constraint (Section 6), we replace $V_1$ and $V_2$ by fresh type variables. Note that this extension still tries to assigns full static types for $\star$ s. As such, this extension will not be find a migration for $\lambda x:\star.x(\mathtt{succ}(x\mathtt{True}))$ , as shown in Section 1.3. The extension in Section 9.2 is able to infer partial static types.

We can extend our type system to support type ascription with the following typing rule.

The second premise ensures that the static parts of the ascribed type G are copied to the second alternative of the choice. The third premise ensures that the type of the expression M is compatible with the ascribed type and also a corresponding type V with all $\star$ types removed. We can update the structure of ${\Omega}$ to accommodate this rule by defining its domain to be program locations rather than parameter names. We use e here as shorthand for the location of e.

Finally, we can also add support for let-polymorphism. The approach is straightforward, but the notations become heavier. We use $\overline{\alpha}$ to denote a list of type variables and $\{\overline{\alpha\mapsto V}\}$ to denote a set that includes $\alpha_{1}\mapsto V_{1},\ldots,\alpha_{n}\mapsto V_{n}$ . The function vars( $\cdot$ ) returns the free type variables in its argument. The typing rules are standard except that when typing variable references (Var) we can only instantiate type schemas with variational types (V) and not migrational types (M).

In support of all of these extensions, the other machinery of our approach, including constraint generation, unification, and extracting the most static migration, can be reused.

9.2 Inferring more precise types

The example in Section 7.1 shows that our approach fails to find a migration for the expression $\lambda x:\star.x(\mathtt{succ}(x\mathtt{True}))$ , even though $\lambda x:\star\to\mathtt{Int}.x(\mathtt{succ}(x\mathtt{True}))$ can be a more precise migration. Recall from Section 6 that during constraint generation we assigned the variational type to the parameter type x and the generated constraint is .

To investigate why our approach cannot find a migration and how we can potentially improve this situation, we list the constraint solving process for the constraint $C_{1}\wedge C_{2}\wedge C_{4}\wedge C_{5}\wedge C_{6}$ below. The first column lists the constraint being solved, and the latter two columns list the unifier and pattern from solving the constraint.

The constraint solving fails when we need to solve the constraint $\alpha\approx^{?}\mathtt{Int}\to\kappa_{8}$ , since our solution before that point contains $\alpha\mapsto\mathtt{Bool}\to\mathtt{Int}$ . When constraint solving fails, the returned pattern is $\perp$ , and the content of the unifier will no longer be used. As a result, we leave the content of the unifier as the same after solving $\alpha\approx^{?}\mathtt{Int}\to\kappa_{8}$ .

The main reason our approach fails to find a migration is that, as we were solving the first constraint $\alpha\approx^{?}\kappa_{1}\to\kappa_{2}$ , we made three requirements: (1) the type that $\alpha$ maps to is constructed by the $\to$ type constructor, (2) the parameter type of $\to$ be a static type, and (3) the return type of $\to$ be a static type. However, in $x\, (\mathtt{succ} (x\ \mathtt{true}))$ , the body of the function, x, is used as functions and applied to both $\mathtt{Bool}$ and $\mathtt{Int}$ values. As a result, no static type could be assigned to x. We can address this problem by relaxing the three requirements for $\alpha$ . To address this problem, we observe that $\alpha$ denotes the type for x when the $\star$ for x is removed, and we are finding a more precise migration than $\star$ . Thus, instead of constraining $\alpha$ with all the three requirements at once, we can relax the latter two requirements and require $\alpha$ be unified with a type whose type constructor is $\to$ only. From now on, we call type variables that are introduced to replace $\star$ s for dynamic parameters migration type variables. Migration type variables appear in the right alternatives of choices when choices are first created. We will use $\alpha$ to range over migration type variables.

Overall, the idea of our solution is that when a migration variable is unified against a function type, we require only that the migration variable be mapped to a function type but allow the parameter type and return type to remain a $\star$ . The typing that happens later decides whether the parameter type and/or return type could be made precise than a $\star$ . As a result, a parameter can now be migrated to a function type whose parameter or return type remains a $\star$ .

One technical challenge is that for the parameter type and return type, we need to explore two possibilities: the $\star$ and a more precise type. Our machinery with variational typing provides a nice solution. Specifically, when a migration variable $\alpha$ is unified with a function type $M_{1}\to M_{2}$ , we refine $\alpha$ to a function type (We refer to this process as refinement) and unify this function type against $M_{1}\to M_{2}$ . Here, $A_1$ , $\alpha_{1}$ , $A_2$ , and $\alpha_{2}$ are fresh and $\alpha_{1}$ and $\alpha_{2}$ are migration variables, which could be further refined to function types whose parameter and return types are $\star$ s. The function type encodes four possibilities: both the parameter type and the return type could be $\star$ or a more precise type.

Following this idea, the constraint solving process for the constraints $C_1$ through $C_7$ is updated to the following. In the “Solution” column below, we omitted the mappings $\alpha$ and $\alpha_{2}\mapsto\kappa_{2}$ to save space.

From Section 6 (page 32), we know that the type of $\lambda x:\star.x(\mathtt{succ}(x \mathtt{True}))$ is . Plugging in the solution for $\alpha$ from the unifier above, the type for $\lambda x:\star.x(\mathtt{succ}(x\mathtt{True}))$ is . Moreover, the pattern for the whole function is . Note, $A_2$ does not appear in the result pattern because whether we choose $\star$ or $\mathtt{Int}$ for the return type of the function type for $\alpha$ , the well-typedness of the expression remains the same. Applying the operations ve and expand, defined in Section 5.2, to the pattern , we know that the best migration for this expression corresponds to the valid eliminator $\{A.2,A_{1}.1,A_{2}.2\}$ . Selecting $M_{dp}$ with $\{A.2,A_{1}.1,A_{2}.2\}$ yields the type $(\star\to\mathtt{Int})\to\mathtt{Int}$ , the type of $\lambda x:\star.x(\mathtt{succ}(x\mathtt{True}))$ after migrating the parameter x. This means that our extension could indeed find a more precise migration for $\lambda x:\star.x(\mathtt{succ}(x\mathtt{True}))$ .

An extension to the unification algorithm Figure 14 presents an extension to the unification algorithm that implements our idea from above. We briefly go through the cases. First, the cases (bR) and (bR*) replace cases (b) and (b*) in Figure 13, by renaming the type variables $\alpha$ to $\beta$ . Note that from now on, we use $\beta$ to denote migration variables and $\beta$ to denote all other variables. The cases (b1) through (b4) handle unification between a migration variable and itself, a constant type, a non-migration type variable, and a variational type.

Figure 14. An extension to the unification algorithm in Figure 13.

Case (b5) handles the unification between a migration variable and a function type. This case uses an auxiliary function AllLvsDynMvs to determine if the leaves of a given input type are all $\star$ s or migration type variables. For example, all $AllLvsDynMvs(\alpha_{1}\to\alpha)$ , $AllLvsDynMvs(\alpha_{2})$ , and $AllLvsDynMvs((\star\to\alpha)\to\alpha_{2})$ are true, while $AllLvsDynMvs(\alpha_{1}\to\mathtt{Int})$ and $AllLvsDynMvs((\alpha_{1}\to\mathtt{Bool})\to\alpha_{2})$ are false. This function helps avoid non-termination in our extension. To illustrate, consider the constraint $\alpha\approx^{?}\alpha\to\beta$ . Such a constraint arises when typing a self application, such as in the expression $\lambda x:\star.x.x$ . This constraint fails to solve using the constraint solving algorithm in Figure 13 due to the occurs check.

With the extension in Figure 14, we will turn the constraint $\alpha\approx^{?}\alpha\to\beta$ into . This constraint encodes four constraints, and one of them is $\alpha_{1}\to\alpha_{2}\approx^{?}(\alpha_{1}\to\alpha_{2})\to\beta$ (if we select the variational constraint with the decision $\{A_{1}.2,A_{2}.2\}$ ). We observe that this problem is larger than the original problem $\alpha\approx^{?}\alpha\to\beta$ and the constraint between the parameter types ( $\alpha_{1}\approx^{?}\alpha_{1}\to\alpha_{2}$ ) resembles the original problem. We can envision that the unification will not terminate if we keep on refining migration variables as we did above.

There are two potential ways to address this problem. The first is that we use a heuristic, such as allowing a single migration variable be refined by up to a certain number of times only. Any further refinement attempt on the same migration variable would be rejected and treated as a unification failure. The second is to detect the unification that unifies a migration variable ( $\alpha$ ) against a function type that contains the migration variable ( $\alpha$ ) and all other leaves are other migration variables or $\star$ s. Such a unification does not reflect any program structure information but is resulted from refining a unification variable to a function type, since constraint generation (Figure 11) does not generate such a constraint. If such a unification problem is detected, we can terminate the unification with a failure.

Note, even though unification will fail for $\alpha_{1}\to\alpha_{2}\approx^{?}(\alpha_{1}\to\alpha_{2})\to\beta$ , which means the typing pattern returned for unifying it will be $\vdash$ , the typing pattern for unifying will not be $\vdash$ . It is . This means that the pattern for solving $\alpha\approx^{?}\alpha\to\beta$ is not $\vdash$ .

In this extension, we use the second way to address this problem. Concretely, we capture it in the first subcase of case (b5). In the second subcase, $\alpha$ does not occur in the function type and all leaves are migration variables, then we directly map $\alpha$ to the function type. In the third subcase, the function type contains some $\star$ s. We need to refine $\alpha$ to a function type, but without creating new variations. The last subcase implements the idea of refining a migration variable into a function type whose both parameter and return types are variations.

With this extension, let’s now turn to finding migrations for the term $\lambda{x}:{\star}.{x\ x}$ . First, we generate the constraint and the type for the term is . This constraint will be solved using case (d) of Figure 13, which will solve two constraints originated from the two alternatives of A. For the left alternative, the constraint is $\star\approx^{?}\star\to\beta$ , which will be solved by case (a) of Figure 13 with the solution ( $\varnothing,\top$ ). For the right alternative, the constraint is $\alpha\approx^{?}\alpha\to\beta$ . This constraint will be handled by the fourth subcase of case (b5) in Figure 14, and it will be transformed to .

With a few steps, this problem can be solved and the solution is and the pattern is . Substituting the type of the term with this solution yields and the overall pattern is . From this pattern, we can use ve and expand defined in Section 5.2 to calculate the strictest valid eliminator $\{A.2,A_{1}.1,A_{2}.2\}$ . Selecting the type with this eliminator leads to the type $(\star\to\beta) \to \beta$ , which is a most static migration for $\lambda{x}:{\star}.{x\ x}$ . This shows that with the extended constraint solving algorithm, we could find a more precise migration for $\lambda{x}:{\star}.{x\ x}$ that we could not find earlier.

9.3 Further migration scenarios

Sections 4 and 5 provide a type system and a method for finding all best migrations. In practice, there may be different migration requirements. In this subsection, we explore a few of them and show how to support them with machinery developed in earlier sections. Specifically, we consider the following migration scenarios.

1. i. Can the programmer control which parameters must or must not be migrated?

2. ii. If migrating a set of indicated parameters yields a type error, can we still migrate a subset of these parameters?

3. iii. Given a set of parameters, can we find which parameters cannot be migrated in unison?

4. iv. Can we find the migrations that migrate the greatest number of parameters?

We use the program $\mathtt{rowAtI}$ to illustrate these scenarios and the development of corresponding machinery. Recall that the variations introduced for the parameters $\mathtt{fixed}$ , $\mathtt{widthFunc}$ , $\mathtt{table}$ , $\mathtt{border}$ , and $\mathtt{i}$ are A, B, D, E, and F, respectively. The typing pattern for this program is shown in Section 4.5 and is reproduced here for readability.

We next go through each scenario.

Scenario i: We begin with a concrete case. Assume that the programmer requires that $\mathtt{table}$ must be migrated and $\mathtt{widthFunc}$ must not be migrated. We can build a decision $\delta_{r}$ for refining the pattern $\pi_{a}$ based on this requirement. To express that $\mathtt{table}$ must be migrated, we extend $\delta_{r}$ with D.2, as D is the variation introduced for $\mathtt{table}$ . For $\mathtt{widthFunc}$ to be not migrated, we extend $\delta_{r}$ with B.1, making $\delta_{r}=\{B.1,D.2\}$ . After that, we refine $\pi_{a}$ with $\delta_{r}$ , yielding the new pattern , which could be simplified to $E\langle\top,\vdash\rangle$ . We can now apply the method developed in Section 5 to the pattern $E\langle\top,\vdash\rangle$ to find the best migrations for $\mathtt{rowAtI}$ while honoring the requirements. Based on the pattern $E\langle\top,\vdash\rangle$ , the migration result is that $\mathtt{border}$ , the parameter corresponds to E, cannot be migrated, and all other parameters can be migrated. Overall, the migration is that we can migrate $\mathtt{fixed}$ , $\mathtt{i}$ , and $\mathtt{table}$ .

In general, for a program and its typing pattern ${\pi}$ generated from MGSM, we follow the following steps to handle this scenario. enumi enumi

1. 1. For each parameter that must be migrated, we extend $\delta_{r}$ with d.2, where d is the variation introduced for the parameter.

2. 2. For each parameter that must not be migrated, we extend $\delta_{r}$ with d.1, where d is the variation introduced for the parameter.

3. 3. We refine the pattern ${\pi}$ with $\delta_{r}$ .

4. 4. With the resulting pattern from the last step, we use the method for finding most static migrations outlined in Section 5.2 to find desired migrations.

Scenario ii: Assume that the programmer requires to migrate all $\mathtt{fixed}$ , $\mathtt{widthFunc}$ , and $\mathtt{table}$ . According to the process of calculating $\delta_{r}$ given earlier, $\delta_{r}=\{A.2,B.2,D.2\}$ . We observe that $\lfloor\pi_{a}\rfloor_{\delta_{r}}=\vdash$ , indicating that not all these parameters can be migrated at the same time. However, the $\vdash$ does not indicate that none of the parameters can be migrated.

To figure out if a parameter within the specified set could be migrated, we could list all decisions yielding best migrations and check if the parameter appears in any set. For example, based on Section 5.2, the decisions corresponding to best migrations for $\mathtt{rowAtI}$ are $\{A.2, B.1, D.2, E.1, F.2\}$ and $\{A.1, B.2, D.2, E.1, F.2\}$ . From the first set, we could decide that $\mathtt{fixed}$ (since $\mathtt{fixed}$ corresponds to A and A belongs to the set) and $\mathtt{table}$ of the desired set could be migrated. From the second set, we could decide that $\mathtt{widthFunc}$ and $\mathtt{table}$ could be migrated. In this case, we have two different such sets. In other cases, we may have only one such set. For example, if the programmer indicated that they wanted to migrate $\mathtt{fixed}$ and $\mathtt{border}$ , then the unique migration corresponds to the decision is $\{A.2, B.1, D.2, E.1, F.2\}$ , indicating that only $\mathtt{fixed}$ within the two parameters could be migrated.

Scenario iii: During program migration, it is quite common that migrating one parameter may preclude the migration of others. For example, in $\mathtt{rowAtI}$ , we could not migrate $\mathtt{widthFunc}$ if we have migrated $\mathtt{fixed}$ and vice versa. Therefore, presenting the unison parameters that could no longer be migrated can be useful to programmers.

Assume that the programmer has migrated $\mathtt{fixed}$ and that we want to calculate the impact it has on other parameters. We must now consider two cases. The first case migrates $\mathtt{fixed}$ , and the decision is $\delta_{r}=\{A.2\}$ . The second case does not migrate $\mathtt{fixed}$ , and the decision is $\delta_{\neg r}=\{A.1\}$ . Let $\pi_{r}$ and $\pi_{r}$ denote the typing patterns resulted from selecting $\pi_{a}$ with $\delta_{r}$ and $\delta_{\neg r}$ , respectively, we have

In the first case, from $\pi_{r}$ , we have two decisions that lead to $\vdash:\{B.1,E.2\}$ and $\{B.2\}$ . In the second case, from $\pi_{\neg r}$ , only one decision leads to $\vdash:\{E.2\}$ . By comparing the decisions in these two cases, we observe that both cases contain E.2. This implies that migrating $\mathtt{border}$ , the parameter corresponding to E, always causes an error, meaning that $\mathtt{fixed}$ being migrated was irrelevant to the reason $\mathtt{border}$ cannot be migrated. On the other hand, only a decision in the first case contains B.2 while none in the second case contains it. This implies that the reason $\mathtt{widthFunc}$ cannot be migrated is because $\mathtt{fixed}$ was migrated. Consequently, the parameter that cannot be migrated in unison with $\mathtt{fixed}$ is $\mathtt{widthFunc}$ .

Given an expression e and ${\pi}$ for its MGSM typing, and assume the parameter x is migrated and the introduced variation for x is d, the following steps list the process of finding parameters that cannot be migrated due to the migration of x.

1. 1. Let $\pi_{r}=\lfloor\pi\rfloor_{d.1}$ and $\pi_{\neg r}=\lfloor\pi\rfloor_{d.2}$ .

2. 2. Collect the decisions that produce $\vdash$ when selecting ${\pi}$ with $\pi_{r}$ .

3. 3. Collect the decisions that produce $\vdash$ when selecting ${\pi}$ with $\pi_{\neg r}$ .

4. 4. For any d’, if $d'.2$ appears in some decisions from step (3) but not from any of decision in step (2), then the parameter that corresponds to d’ cannot be migrated in unison with x.

Scenario iv: This scenario aims to find out the migrations that migrate the greatest number of parameters, which we refer to as maximal migrations. For example, if one most static migration migrates two parameters while another migrates four, then the latter is a maximal migration if no other migrations migrate more than four parameters. In some situation, maximal migration are not unique. For example, two most static migrations for $\mathtt{rowAtI}$ migrate three parameters and both are maximal.

Given an expression and its typing pattern ${\pi}$ for its MGSM, a simple process to find maximal migrations is generate all best migrations from ${\pi}$ and filter out the migrations that migrate the greatest number of parameters.

This process is straightforward and necessitates no changes to our existing machinery, but is computationally expensive. We can improve the efficiency by slightly adapting the ve function for collecting best migrations from Section 5.2. Specifically, for each internal node of the typing pattern, we compare the cardinality of the decisions from the left and right subtrees and discard the decisions that have more left selectors, which are selectors of the form d.1 for some d (see Section 2.2). We express this idea in the following function mve.

In the definition, $\delta|_{1}$ (introduced in Section 4.5) returns all left selectors in $\delta$ . The notation lmve[0] returns any member from the set lmve. This is valid because all of the members in lmve include the same number of left selectors, and so do those in rmve. The set $\mathscr{D}$ (introduced in Section 5.2) contains all variations introduced in typing e. Note, given a decision $\delta$ , if $d.1\in\delta$ then the parameter corresponding to d cannot be migrated. Therefore, $|\mathscr{D}| - |lmve[0]|_{1}|$ gives the number of parameters that can be migrated in lmve[0].

mve is always more efficient than ve since the former keeps the set of decisions that yield maximal migrations only while the latter keeps all best migrations. In particular, if there is a unique maximal migration, then mve returns only one decision.

Discussion. Supporting these scenarios by reusing or slightly adapting existing machinery demonstrates the generality of our approach. We can also support variations or combinations of scenarios we looked at with ease. For example, a combination of scenarios i and iv could be supported by following the first three steps outlined in Scenario i and then applying the mve function to the resulting pattern. As another example, we may be interested in the scenario of finding the maximal migration within a given set of parameters. To support this scenario, we first select the typing pattern of the MGSM typing with selectors of the form d.1, where d corresponds to a parameter that does not belong to the given set. The selection result is a pattern, to which we apply mve to find the maximal migration within that parameter set.

Overall, the generality of our approach demonstrates that it could be a useful foundation for developing more complex and significant migration supports in practice.

11.1 Annotation upgrading and migratory typing

Tansey & Tilevich (Reference Tansey and Tilevich2008) studied the problem of automatically upgrading annotations (such as types and access modifiers in Java) in legacy applications in response to the upgrading of, for example, testing frameworks and libraries. This is similar to our work in that it tackles the problem of migrating programs to a new version by changing annotations in the program. Their methodology is quite different; however, in that it needs two example programs illustrating how annotations change between framework versions, so that their inference rules can learn the changes made in the examples. In contrast, our approach only needs to reason about how type annotations affect the typing of the program, so migrating annotations requires only information attainable through the type system.

Moreover, the kind of migrations are orthogonal. Their goal is to upgrade an entire codebase automatically to use a new framework, which means that they have one endpoint. Migrational typing presents all of the ways a programmer might want to change the types of their program by adjusting $\star$ annotations, meaning that there are multiple endpoints.

Migratory typing (Tobin-Hochstadt et al., Reference Tobin-Hochstadt, Felleisen, Findler, Flatt, Greenman, Kent, St-Amour, Strickland and Takikawa2017) provides another approach to migrating dynamically typed code to statically typed code by creating a statically typed sister language that interfaces seamlessly with the dynamically typed language. In general the focus of this work is about designing such a sister language such that types can be assigned to existing programs in the dynamic language with minimal refactoring. While programmers have to manually add type annotations to make programs more static in migratory typing, migrational typing supports systematically typing the whole migration space and automatically finding the best migrations.

This means that a large focus of migratory typing is orthogonal to our work in that we assume we are working within a given gradual language and that we do not have to design a static sister language to a dynamic language. On the other hand, if we were given a static language and gradualized it via the idea of Garcia et al., (Reference Garcia, Clark and Tanter2016), Cimini & Siek (Reference Cimini and Siek2016); Cimini & Siek (Reference Cimini and Siek2017) we conjecture we could design a migration tool for gradualized languages that supported unification based type inference.

11.2 Gradual typing migration

As discussed in Section 1.3, this work is closely related to the work by Migeed & Palsberg (Reference Migeed and Palsberg2019) on finding maximal migrations for gradual programs. There are several similarities in their work and ours. For example, they consider a set of possible migrations for a gradually typed programs and try to find all of the maximal migrations. These maximal migrations are migrations that cannot add any more type information to the program without causing a static type error, which are similar to our most static migrations. They show that the process of finding maximal migrations is NP hard.

Their work has some notable differences with our work, however. Mainly, the language they consider is a version of GTLC (Siek et al., Reference Siek, Vitousek, Cimini and Boyland2015) with the ability to add $\mathtt{Bool}$ and $\mathtt{Int}$ annotations. In contrast, we start with ITGL, a gradualized version of the Hindley-Milner language, which has a principal type inference that works on unannotated terms. Essentially, while both work aims to find maximal migrations, they use different techniques and criteria. In their work, they continuously generate more precise programs by replacing a $\star$ with a more precise type and tests the well-typedness of the generated program. They find a maximal migration if no more $\star$ s exist or no more $\star$ could be replaced with any more precise type. A migration in our work is maximal if no further $\star$ can be eliminated with respect to ITGL Garcia & Cimini (Reference Garcia and Cimini2015) constraint solving. As a result, their approach may find types that are rejected by the ITGL inference that we adapt. For example, for $\lambda x:\star.x(succ(x\mathtt{True}))$ , their approach infers that x can be given the type $\star\to\mathtt{Int}$ , whereas our approach respects ITGL, which considers the use of x to be ill-typed (Our extension in Section 9.2 does infer that x may be migrated to the type $\star\to\mathtt{Int}$ .

Finally, we have evaluated the efficiency of our approach on large programs, and we observed that finding all best migrations in our approach is usually within a factor of 2 of typing each possible migration. The efficiency in their approach is unclear. It would be interesting as future work to see if our machinery could be exploited to improve the efficiency of their work.

Phipps-Costin et al., (Reference Phipps-Costin, Anderson, Greenberg and Guha2021) developed a framework named TypeWhich for migrating gradual types. While both our work and the work by Migeed & Palsberg (Reference Migeed and Palsberg2019) aim at maximizing type precision during migration, TypeWhich allows users to consider not only type precision, but also type safety (such that migration does not introduce runtime errors) and type compatibility (such that migration does not break the interoperability between migrated and un-migrated code). As such, some migrations in our work and that by Migeed & Palsberg (Reference Migeed and Palsberg2019) may introduce dynamic runtime errors, but not in the safety or compatibility mode of TypeWhich. The latter two modes are particularly useful because migrations are often not done for the whole project and the migration process should not break code interactions.

In addition, our work and TypeWhich differ in many aspects. First, our work can find all best migrations for a given program whereas TypeWhich finds just one best migration by default. Further migrations may be returned by TypeWhich through model extraction by the underlying SMT solver. While returning the first model is efficient, the complexity of extracting all migrations is unclear.

Consider, for example, the following expression.

\begin{equation*}\mathtt{width fixed widthFunc = 2 + (if fixed then widthFunc fixed else widthFunc 33)}\end{equation*}

TypeWhich displays the following migration first for this function when prioritizing type precision.

Our work finds two best migrations for the function $\mathtt{width}$ , and neither is more precise than the other. In the first migration, the type for $\mathtt{fixed}$ remains to be $\star$ whereas the type for $\mathtt{widthFunc}$ is $\mathtt{Int}\to \mathtt{Int}$ , as shown below.

In the second migration, the type for $\mathtt{fixed}$ is migrated to $\mathtt{Bool}$ and the type for $\mathtt{widthFunc}$ is migrated to $\star->\mathtt{Int}$ (without the extension in Section 9.2 the type for $\mathtt{widthFunc}$ will remain $\star$ ). The migrated program is shown below.

For programs that cannot be fully statically typed, it is likely that hundreds of best migrations exist. Our approach finds all of them in time linear to the size of the program. Since our approach may find a large number of best migrations simultaneously, it is helpful to allow users to specify preferences about where migrations are desired. We support them through extensions in Section 9.3. Since TypeWhich finds best migrations sequentially, developing such supports could be harder.

Second, by design, TypeWhich may ascribe a $\star$ type to a subexpression even though the subexpression has a static type during static type checking. This design allows more parameters to be migrated when precision is maximized. For example, in the migration for $\mathtt{width}$ above, TypeWhich ascribed $\star$ to $\mathtt{fixed}$ that has the type $\mathtt{Int}$ for the condition so that $\mathtt{fixed}$ can be used where a $\mathtt{Bool}$ is needed. Without the ascription, the migrated program is statically ill-typed. Our approach does not use ascription for maximizing migrations. Third, our approach supports polymorphism through let (Section 9.1) while TypeWhich does not.

Henglein & Rehof (Reference Henglein and Rehof1995) developed an approach for embedding Scheme programs in ML by inserting coercions into subexpressions whose type correctness cannot be statically verified. Their approach uses type inference to reduce coercions that will be inserted, making it behave similarly to TypeWhich that prioritizes type safety. Technically, their approach is more involved. Given a program, it collects typing constraints, builds a simple value flow graph, and decides where coercions are needed.

11.3 Relation to gradual typing

Work on gradual typing can be broadly defined along three dimensions. The first investigates the integration of gradual typing with advanced typing features, such as objects (Siek & Taha Reference Siek and Taha2007), ownership types (Sergey & Clarke Reference Sergey and Clarke2012), refinement types (Wadler & Findler Reference Wadler and Findler2009; Lehmann & Tanter Reference Lehmann and Tanter2017; Jafery & Dunfield Reference Jafery and Dunfield2017; Williams et al., Reference Williams, Morris and Wadler2018), session types (Igarashi et al., Reference Igarashi, Thiemann, Vasconcelos and Wadler2017), and union and intersection types (Siek & Tobin-Hochstadt Reference Siek and Tobin-Hochstadt2016; Castagna & Lanvin Reference Castagna and Lanvin2017; Toro & Tanter Reference Toro and Tanter2017; Castagna et al., Reference Castagna, Lanvin, Petrucciani and Siek2019). From this perspective, our type system studies the combination of variational types with gradual types. Gradual languages with type inference (Siek & Vachharajani Reference Siek and Vachharajani2008; Rastogi et al., Reference Rastogi, Chaudhuri and Hosmer2012; Garcia & Cimini Reference Garcia and Cimini2015) were a large influence on migrational typing. While ITGL was used as the basis for formalizing our type system, we expect that our approach can be extended to handle other features in this line of work. The reason is that the idea and manipulation of variations is orthogonal to other type system features. In particular, the idea of type compatibility in Section 4.2 and the handling of type errors in Section 4.3 can be easily extended.

The second dimension studies runtime error localization and performance issues with sound gradual typing. The blame calculus (Tobin-Hochstadt & Felleisen Reference Tobin-Hochstadt and Felleisen2006; Wadler & Findler Reference Wadler and Findler2007; Wadler & Findler Reference Wadler and Findler2009) adapts the contract system notion of blame so that less precise parts of a program are blamed when cast errors occur. Ahmed et al., (Reference Ahmed, Findler, Siek and Wadler2011, Reference Ahmed, Jamner, Siek and Wadler2017) extended that work to further handle polymorphic types. Since those works, there has been a number of papers involving parametricity in the gradually typed setting (Toro et al., Reference Toro, Labrada and Tanter2019; New et al., Reference New, Jamner and Ahmed2019). Takikawa et al., (Reference Takikawa, Feltey, Greenman, New, Vitek and Felleisen2016) showed that sound gradually typed languages suffer from performance issues as more interactions between static code and dynamic code leads to frequent value casts. Confined Gradual Typing (Allende et al., Reference Allende, Fabry, Garcia and Tanter2014) provides constructs to control the flow of values between static and dynamic code, mitigating performance issues and making gradual typing more predictable.

The final dimension studies the production of gradual type systems from specifications of static type systems. For example, Garcia et al., (Reference Garcia, Clark and Tanter2016) presented a way to create gradual type systems from static ones using techniques from abstract interpretation. The Gradualizer (Cimini & Siek Reference Cimini and Siek2016, Reference Cimini and Siek2017) can produce a gradual type system and dynamic semantics for a statically typed language given its formal semantics. It is thus interesting to investigate how these approaches interact with variations in the future. Siek et al., (Reference Siek, Vitousek, Cimini and Boyland2015) discussed the criteria for gradual typing. We employed the criteria of the underlying ITGL to prove Theorem 7.

11.4 Type inference

The goal of gradual typing is to find out what parameters can be given static types. As such, gradual typing is closely related to the idea of type inference.

Gradual type inference with flow-based typing (Rastogi et al., Reference Rastogi, Chaudhuri and Hosmer2012) has been explored to make programs in dynamic object-oriented languages more performant. Since our work is formalized on ITGL, our work inherits the relations between ITGL and flow-based inference (Garcia & Cimini Reference Garcia and Cimini2015). Additionally, while flow-based inference ensures that inferred type annotations do not cause runtime errors, our current formalization does not have this property as our approach is not flow-directed.

The inference in flow (Chaudhuri et al., Reference Chaudhuri, Vekris, Goldman, Roch and Levi2017) is also flow-based and was specifically designed to not produce false positives for idioms that are commonly used in JavaScript. It is possible that migrational typing can help the inference process for languages like JavaScript by using variations to reason about idioms in messy scenarios. A flow-based inference was also employed over Reticulated Python’s cast inserted transient translation. The inference was used to optimize program performance, removing unnecessary casts where the inference indicated that it was safe.

A few type systems, such as Guha et al., (Reference Guha, Saftoiu and Krishnamurthi2011), Chugh et al., (Reference Chugh, Rondon and Jhala2012), Pearce (Reference Pearce2013), support flow-based reasoning but do not perform type inference.

SimTyper, developed by Kazerounian et al., (Reference Kazerounian, Foster and Min2021), aims to infer usable types for Ruby. Unlike most type inference algorithms, the goal of SimTyper is not to infer most general (precise) types, which could be verbose and hard to use in presence of subtyping, structural types, overloading, and other dynamic language features. Instead. the goal of SimTyper is to infer usable types that programmers often write. SimTyper is built on InferDL Kazerounian et al., (Reference Kazerounian, Ren and Foster2020), a heuristics-based type inference algorithm, and a type equality prediction method based on machine learning. Essentially, when SimTyper discovers an overly general, complicated type, it uses the type equality predictor to find a type that is more concise and is equal. SimTyper then uses that more concise type to replace the complicated one and check if that replacement violates any typing constraint. It accepts the concise type if no violations detected and rejects the type and look for another concise type otherwise.

Wei et al., (Reference Wei, Goyal, Durrett and Dillig2020) developed LambdaNet for inferring types for TypeScript. Given a program, LambdaNet first transforms it to a type dependency graph, where nodes are type variables for subexpressions in the programs and hyperedges express constraints (such as the subtyping relation or type equality). Hyperedges may also provide hints to type inference, such as variables giving rise to the connected type variables have similar names. All type variables are then converted to vectors of numbers (known as embedding in machine learning) and, LambdaNet uses a set of rules to propagate type information across the dependency graphs. These rules manipulate the embedding in each node. As with deep learning (Neocleous & Schizas Reference Neocleous and Schizas2002), the intuitions behind such rules are unclear. Finally, after propagation completes, inferred types are readout from embeddings.