2.1 Syntax

The syntax of $\lambda_B$ and $\lambda_\star$ are both given in figure 1. Since $\lambda_B$ is an extension of $\lambda_\star$ , they share some common syntactic categories. The parts without highlighting are common to both of them, the light-gray highlighted part belongs to $\lambda_B$ , and the gray highlighted part belongs to $\lambda_\star$ . In other words, $\lambda_B$ extends $\lambda_\star$ by substituting light-gray part for dark-gray part in $\lambda_\star$ . In this paper, the denotation of shared syntactic symbols will be clear from context.

Fig. 1.

Syntax of $\lambda_\star$ and $\lambda_B.$

We let G,T or S range over types. A gradual type is either a base type $\iota$ , the dynamic type $\star$ , a function type $T \to S$ , or a record type $\{\overline{l_i : G_i} \}$ . Each field label l belongs to a countably infinite set $\mathcal{L}$ , which is assumed to be disjoint with other syntactic categories. With subscripted $\star$ , type metavariables $G_\star,T_\star$ and $S_\star$ indicate gradual types that are not $\star$ . Note that types like $\star \to \star,\{l:\star\}$ are still $G_\star$ types. We give an inductive definition of them in Figure 1. We let x,y,z range over term variables, which belong to another countably infinite set $\mathcal{V}$ . We let t range over terms, and e,s range over expressions.

An expression is a term with a context label attached to it. In the source code of a gradually typed programming language, a context label is merely a syntactical program label $\omega$ which belongs to another denumerable set $\Omega$ . In the semantics Section 2.2, we will explore how context labels can be employed to identify and subsequently track the evaluation of expressions in the source code. Importantly, context labels have no impact on the semantics of $\lambda_B$ . In Section 3, context labels play a fundamental role in Static Blame as the definition of type flow is based on them. Consequently, the entire type flow analysis algorithm relies on context labels.

A context label also contains a list of context refinements to denote newly generated contexts during compilation and evaluation, the precise meaning will be explained later in the semantics Section 2.2.

A term may be a variable x, a constant c, a lambda expression $\lambda x:G. e$ , an application $e_1 e_2$ , a record $\{\overline{l_i = e_i} \}$ , a record projection $e.l$ , or a conditional expression $\mathrm{\texttt{if}}\ e_1\ \mathrm{\texttt{then}}\ e_2\ \mathrm{\texttt{else}}\ e_3$ .

Terms of $\lambda_\star$ also contain ascription $e :: G$ , which does not exist in the blame calculus $\lambda_B$ . Ascriptions denote manual type casts by programmers and will be replaced by explicit type casts in $\lambda_B$ during translation. A type cast $\langle S \Leftarrow^b T \rangle e $ denotes casting the type of term t from T to S at run-time and is identified by a blame label b which is also a program label. In this paper, $\langle T_1 \Leftarrow^{b_1} T_2 \Leftarrow^{b_2} T_3 ... T_n \Leftarrow^{b_n} T_{n+1} \rangle$ is an abbreviation of the sequence of casts $ \langle T_1 \Leftarrow^{b_1} T_2 \rangle \langle T_2 \Leftarrow^{b_2} T_3 \rangle ... \langle T_n \Leftarrow^{b_n} T_{n+1} \rangle$ . Whenever employing this abbreviation, we will provide further clarification if it is not trivial to omit context labels.

The reuse of context label as blame label is nothing deep. It is just a convenient way to make the compilation process deterministic, which needs to generate fresh blame label to identify different type casts occurring in the compiled program. The blame label itself is just an identifier to distinguish different casts without additional semantics. Therefore, the main task of the blame label generation process is to ensure that different casts have different blame labels in the compilation result (see Proposition 2.9).

We also assume a denumerable set of constants as the definition of blame calculus of Walder and Findler (2009). Constants include values of base types and operations on them. Therefore, each constant is static. Specifically, We assume a meta function ty that maps every constant to its predefined type in the standard way. For example, $ty(\mathrm{\texttt{true}})$ and $ty(\mathrm{\texttt{false}})$ are defined as type Bool, while $ty(+)$ and $ty(-)$ are defined as $\mathrm{\texttt{Int}} \to \mathrm{\texttt{Int}} \to \mathrm{\texttt{Int}}$ . Being static means that for any constant c, the type ty(c) does not contain any $\star$ within it.

Since $\lambda_\star$ is a gradually typed language extended by subtyping relation, consistent subtyping $T <' S$ is used in typing rules rather than consistency. The declarative definition of consistent subtyping is given in Figure 1 along with standard consistency. The distinction between $T <' S$ and consistency is the width subtyping rule for records.

Consistency is a structural relation. A base type is consistent with itself. A dynamic type is consistent with every type. Two function types are consistent if their domains and ranges are consistent. Two record types are consistent if they have the same fields and their fields are consistent. We refer to Garcia et al. (Reference Garcia, Clark and Tanter2016) for more details about the design principle of consistency relation.

The consistent subtyping relation merely extends standard subtyping relation with two additional rules stating that a dynamic type $\star$ satisfies consistent subtyping with any gradual type in both directions. This definition shows that consistent subtyping is mostly a structural relation. $T <' S$ if every pair (T’,S’) of corresponding parts in type trees of T and S satisfies subtyping relation or one of them is $\star$ . We refer to Xie et al. (Reference Xie, Bi, d. S. Oliveira and Schrijvers2020) for a fairly comprehensive research of consistent subtyping.

Figure 2 describes the static type system and translation relation of $\lambda_\star$ simultaneously. By omitting the highlighted parts, it defines the type system of $\lambda_\star$ as a ternary relation $\Gamma \vdash e : G$ . And by adding the highlighted parts, it defines the translation static semantics as a relation $\Gamma \vdash t \rightsquigarrow s : G$ , where s denotes terms in $\lambda_B$ .

Fig. 2.

Static semantics of $\lambda_\star.$

We let $\Gamma$ range over type environments, which are partial functions that map term variables into gradual types and are represented by unordered sets of pairs $x:G$ . The extension of type environment $\Gamma,(x:G)$ is an abbreviation of set union, where we assume the new variable x is not in the domain of $\Gamma$ .

There are two points we need to clarify in Figure 2. First, the rule T_If involves a join operator $\vee$ ensuring that branches of a conditional expression can have different types.

Definition 2.1 ( $\vee$ and $\wedge$ ). The operation $\vee$ and $\wedge$ is defined as

\begin{align*} &\star \vee G = G \vee \star = \star \quad \star \wedge G = G \wedge \star = G \quad \iota \vee \iota = \iota \wedge \iota = \iota \\ &(T_{11} \to T_{12}) \vee (T_{21} \to T_{22}) = (T_{11} \wedge T_{21}) \to (T_{12} \vee T_{22}) \\ &(T_{11} \to T_{12}) \wedge (T_{21} \to T_{22}) = (T_{11} \vee T_{21}) \to (T_{12} \wedge T_{22}) \\ &\{ \overline{l_i:T_{i1}}, \overline{l_j:T_j} \} \vee \{ \overline{l_i:T_{i2}}, \overline{l_k:T_k} \} = \{ \overline{l_i:T_{i1} \vee T_{i2}}\} &\mathrm{, where }\{\overline{l_j}\} \cap \{\overline{l_k}\} = \emptyset \\ &\{ \overline{l_i:T_{i1}}, \overline{l_j:T_j} \} \wedge \{ \overline{l_i:T_{i2}}, \overline{l_k:T_k} \} = \{ \overline{l_i:T_{i1} \wedge T_{i2}}, \overline{l_j:T_j}, \overline{l_k:T_k} \} &\mathrm{, where }\{\overline{l_j}\} \cap \{\overline{l_k}\} = \emptyset \\\end{align*}

If defined, $T \vee S$ is a common consistent supertype of T and S, while $T \wedge S$ is a common consistent subtype of T and S.

Second, the translation process requires context refinement by $\blacktriangleleft$ for every newly generated sub-expression. The symbol $\blacktriangleleft$ is used for cast expressions. The expression with the label $p\blacktriangleleft$ will be cast to the expression with label p. For example, in T_App the argument expression $e_2$ in $\lambda_\star$ is assumed to be translated to an expression $t_2^{\,p_2}$ , and a cast is inserted to form a new argument expression $(\langle T_1 \Leftarrow^{\,p_2} T_2 \rangle t_2^{\,p_2\blacktriangleleft})^{\,p_2}$ in $\lambda_B$ . We let the new argument expression keep the label $p_2$ after translation. To maintain the uniqueness of context labels (Proposition 2.9), the label of the term $t_2$ is a refined label $p_2\blacktriangleleft$ , which means “the value of this expression will be cast to the value of $p_2$ ”. Similarly in T_AppDyn and T_If, this kind of context refinement by $\blacktriangleleft$ happens where casts are inserted. Note that T_Ann does not need context refinement, since an ascription is directly transformed into a cast and no new sub-expression is generated. Other type rules are standard.

Definition 2.3 (sub-expressions and $\mathfrak{S}(e)$ ). The sub-expressions of an expression e in $\lambda_\star$ or $\lambda_B$ , denoted by $\mathfrak{S}(e)$ , is a multi-set defined by

The light-gray highlighted part belongs to $\lambda_B$ , and the gray highlighted part belongs to $\lambda_\star$ . Other parts are common.

Now we can formally assert that our representation of blame label is appropriate.

Well-labeled is just an auxiliary definition to formalize the assumption that every sub-expression has a unique label attached to it.

The proposition we need to prove is a direct corollary. Indeed, in the translation process defined in Figure 2, the newly generated blame labels are always the out-most attached context labels of the (translation result of) direct sub-terms. Since these context labels do not occur as blame labels in these direct sub-terms, the generated blame labels are therefore fresh.

Recall that every context label p occurs at most once in e. Moreover, we give two trivial observations about $\Gamma \vdash e \rightsquigarrow t^p : G$ without proof: (1) p must occur in e as an attached label (2) if a cast $\langle S \Leftarrow^{\,p'} T \rangle$ occurs in t, then p’ must occur in e as an attached label.

Induction on $\Gamma \vdash e \rightsquigarrow t^p$ . Case T_Var and Case T_Con are direct.

Case T_Ann: $\Gamma \vdash e \rightsquigarrow t^{\,p_1} :T$ and $\Gamma \vdash (e :: G)^{\,p_2} \rightsquigarrow (\langle G \Leftarrow^{\,p_1} T \rangle t^{\,p_1})^{\,p_2}$ . From the induction hypothesis and our observation, there is no cast with blame label $p_1$ or $p_2$ occurs in t, thus the conclusion holds for $(\langle G \Leftarrow^{\,p_1} T \rangle t^{\,p_1})^{\,p_2}$ .

Case T_Lam: $\Gamma, (x:G) \vdash e \rightsquigarrow s :T$ and $\Gamma \vdash (\lambda x:G.e)^{\,p} \rightsquigarrow (\lambda x:G.s)^{\,p} : G \to T$ . From our observation, p does not occur as a blame label in s. Apply the induction hypothesis, we know that every p occurs in s as a blame label at most once. Then the conclusion holds for $(\lambda x:G.s)^{\,p}$ .

Case T_AppDyn: $\Gamma \vdash e_1 \rightsquigarrow t_1^{\,p_1} : \star$ and $\Gamma \vdash e_2 \rightsquigarrow t_2^{\,p_2} :G$ . The result is $e = ((\langle \star \to \star \Leftarrow^{\,p_1} \star \rangle t_1^{\,p_1\blacktriangleleft} )^{\,p_1} (\langle \star \Leftarrow^{\,p_2} G \rangle t_2^{\,p_2\blacktriangleleft})^{\,p_2})^{\,p_3} $ . By the induction hypothesis and our observation, we know that $p_1,p_2,p_3$ does not occur as a blame label in $t_1$ , nor in $t_2$ . Then the conclusion holds for e. Other cases are similar.

2.2 Semantics of $\lambda_B$ Lg

The whole definition of $\lambda_B$ is given in Figure 3, extending the syntax in Figure 1. As an intermediate language of gradual languages, the type system and runtime semantics of $\lambda_B$ are standard. We let u,v,w range over values, r over intermediate evaluation results, and E over evaluation contexts. A value expression $v^p$ is an expression whose inner term v is a value. A value v is either a constant, a variable, a function, a record where each field is a value expression, a cast between functions or records, or an injection into dynamic from a non-dynamic type. Note this definition of value admits unbounded accumulation of casts on values.

Fig. 3.

The language $\lambda_B.$

Since $\lambda_B$ is an extension of $\lambda_\star$ , we reuse the relation $\Gamma \vdash e : G$ to represent the type system of $\lambda_B$ . $\lambda_B$ is a statically typed language. For a program t in $\lambda_\star$ , it is trivial that $\emptyset \vdash e \rightsquigarrow s : G$ implies $\emptyset \vdash s : G$ .

We use a binary relation $e \longrightarrow r$ to indicate a single-step reduction from an expression e to a result r. We say an expression e is a $\longrightarrow$ -redex if there exists an r such that $e \longrightarrow r$ . The standard reduction relation $e \longmapsto r$ is a simple closure of $\longrightarrow$ . By induction, if e can be decomposed to E[e’] as a combination of an evaluation context E and a $\longrightarrow$ -redex e’, then e can reduce in one step by reducing e’ in one step. We use $e \longmapsto^* r$ to indicate zero or more steps of reduction.

The reader can disregard the manipulation of context labels momentarily and observe that the definition of $e \longrightarrow r$ is straightforward. A detailed explanation of context label manipulation will will be provided later. We assume an interpreting function $[\![ ]\!]$ which interprets a constant c with respect to ty(c). If ty(c) is a function type, we assume the return value of $[\![ c ]\!] $ is still a constant. For example, $[\![ + ]\!] v$ is itself a constant which can be interpreted as a computable function that maps any integer n to the result of $v+n$ if v is an integer, and undefined otherwise. Rules for application, record projection, conditional expression, cast elimination, and cast decomposition are standard. Note that we also give a rule concerning record type besides function type. A cast between two record types is resolved into a less complicated cast between types of the fields being accessed.

In Figure 3, blame is always assigned to the downcast. Therefore, $\lambda_B$ resembles the D strategy in Siek et al. (Reference Siek, Garcia and Taha2009). Static Blame is easy to migrate between different blame strategies by simply changing the process of flow analysis that will be introduced in Section 3 to match the runtime semantics.

Now we give a detailed explanation of context label manipulation in reduction. Note that context labels occurring in an expression do not affect its evaluation. The general design principle which we will prove later is that if $t_1^{\,p_1} \longmapsto t_2^{\,p_2}$ then $p_1 = p_2$ . In other words, context label is a way to track evaluation steps similar to program labels in standard flow analysis. As a result, $t[x := v]$ is still defined as a term substitution to preserve attached context labels. More specifically, $x^p[x := v]=v^p$ .

Additionally, context labels enable us to encode type cast, specifying both the source and the target. For a type cast expression $(\langle S \Leftarrow^b T \rangle t^{\,p_1})^{\,p_2}$ , we can interpret it not only as “the type of t is cast to S” but also as “the value of expression $p_1$ will become the value of expression $p_2$ through the cast $\langle S \Leftarrow^b T \rangle$ ”. By regarding type casts as a special form of value passing, it becomes possible to statically infer all possible combinations of type casts if one can obtain all flow information within the program. This is precisely the approach employed by Static Blame as formally demonstrated in Corollary 3.15.

As in compilation relation, context refinement happens when cast expressions are generated. The refined context label p attached to an expression $t^p$ expresses which expression $t^p$ will cast to. For example, in function cast decomposition,

$${\color{blue}(} {\color{cyan}(}\langle T_1\to S_2 \Leftarrow^b S_1 \to T_2 \rangle v^{p_1}{\color{cyan})}^{\,p_2} w^{\,p_3}{\color{blue})}^p \longrightarrow {\color{blue}(}\langle S_2 \Leftarrow^b T_2 \rangle {\color{orange}(}v^{p_1} {\color{red}(}\langle S_1 \Leftarrow^b T_1 \rangle w^{\,p_3} {\color{red})}^{\,p_1?}{\color{orange})}^{\,p_1!} {\color{blue})}^p $$

the generated expression ${\color{red}(}\langle S_1 \Leftarrow^b T_1 \rangle w^{\,p_3} {\color{red})}^{\,p_1?}$ will be cast to the argument of the expression $v^{p_1}$ inside the left hand. Therefore, it has the refined context label $p_1?$ . Also, note that abandoning the context label $p_2$ is acceptable in this reduction rule. First, considering that $v^{p_1}$ is a value, we already know that the only possible value that will flow into $p_2$ is exactly $v^{p_1}$ . Second, the expression $p_2$ will be eliminated and disappear after reduction. Consequently, preserving the context label $p_1$ is sufficient to maintain the necessary information for the remaining reduction steps.

Static Blame has four different kinds of context refinement $\epsilon$ , namely $\blacktriangleleft$ , $?$ , $!$ and l. All of them express a cast-to relation. In detail, an expression with context label $p\blacktriangleleft$ means that e will cast to an expression with context label p; an expression with context label $p?$ (resp. $p!$ /pl) means that e will cast to a parameter (resp. a return value/an l field) of expressions with context label p. The concept context refinement is highly inspired by the concept “type kind” in Rastogi et al. (Reference Rastogi, Chaudhuri and Hosmer2012) and shares the same notation. It also has something in common with the concept “Tag” in Vitousek et al. (Reference Vitousek, Swords and Siek2017), and a more detailed discussion is listed in related work.

We conclude this section with several formal properties of $\lambda_B$ .

The determinism of our semantics is ensured by the unique decomposition theorem.

The type safety property consists of a progress lemma and a preservation lemma. The progress lemma is a corollary of the unique decomposition theorem.

3.1 Labeled type and type flow

Recall that the main purpose of the Static Blame framework is to exploit data flows and develop a correspondence between static constraints and runtime behavior. The Static Blame framework achieves its goal with the concept of type flow which corresponds straightforwardly to type cast, and the type flow analysis which computes type flows statically.

The syntax of labeled type and type flow is given in Figure 4. Type flow consists of labeled types. As we explained in Section 1.3, a labeled type is an identifier used for tracking expression evaluation as program labels in standard flow analysis. Formally, a labeled type $\hat{G}$ is just a pair $\langle G,p \rangle$ of a gradual type G and a context label p. By intuition, the labeled type represents an expression $t^p$ in $\lambda_B$ with the same context label. The gradual type G is a design redundancy since $\lambda_B$ is a statically typed language. The type of an expression e will not change during evaluation by preservation property. This redundancy gives Static Blame a straightforward correspondence: for a cast expression $(\langle S \Leftarrow^b T\rangle t^{\,p_1})^{\,p_2}$ , it corresponds to type flow $\hat{T} \triangleright_b \hat{S}$ where $\hat{T} = \langle T,p_1 \rangle$ and $\hat{S} = \langle S,p_2 \rangle$ . Similarly, for a cast combination $(\langle T_{n+1} \Leftarrow^{b_n} T_n ... T_3 \Leftarrow^{b_2} T_2 \Leftarrow^{b_1} T_{1} \rangle t^{\,p_1})^{\,p_{n+1}}$ where the omitted context labels are $p_2...p_n$ , it corresponds to a type flow combination $\hat{T_1} \triangleright_{b_1} ... \triangleright_{b_n} \hat{T}_{n+1}$ where $\hat{T_i} = \langle T_i, p_i \rangle$ . The notation $\hat{T_1} \triangleright_{b_1} ... \triangleright_{b_n} \hat{T}_{n+1}$ is an abbreviation for a collection of type flows $\hat{T_1} \triangleright_{b_1} \hat{T_2}, \hat{T_2} \triangleright_{b_2} ... \hat{T}_{n} \triangleright_{b_n} \hat{T}_{n+1}$ .

Fig. 4.

Syntax for labeled type and type flow.

Type flow is an instance of constraint in standard flow analysis. Static Blame views a cast expression as a special value passing monitored by the blame mechanism. By intuition, a type flow $\langle T,p_1 \rangle \triangleright_b \langle S,p_2 \rangle$ means that the value of expression $t_1^{\,p_1}$ will be passed into expression $t_2^{\,p_2}$ , and a blame may be assigned to b if cast fails. In contrast, the ordinary value passing and variable binding relations are not monitored by the blame mechanism and are denoted by the dummy kind d, which serves as a flag that is distinct from any blame label.

The whole type flow generation process consists of a dummy type flow generation process and a direct conversion from type casts to non-dummy type flows. The definition of dummy type flow generation relation $\Gamma \vdash e : G \mid C$ is given in Figure 5, where e is an expression in $\lambda_B$ , G is a gradual type, and C is a set of dummy type flows. Most rules mirror the control flow constraint generation in standard flow analysis.

Fig. 5.

Dummy type flow generation for $\lambda_B.$

Note that $\Gamma \vdash e : G \mid C$ is a deterministic relation. The following proposition is trivial.

The whole type flow generation process is formally defined as a function $\varphi$ .

Definition 3.3 ( $\varphi(\Gamma,e)$ ). For an expression e and a type environment $\Gamma$ , suppose that there exists G,C such that $\Gamma \vdash e : G \mid C$ , we define the collection of generated type flows of e under $\Gamma$ as

\begin{equation*} \varphi(\Gamma,e) = \{ \langle T, p_1 \rangle \triangleright_b \langle S,p_2 \rangle \mid (\langle S \Leftarrow^b T\rangle t^{\,p_1})^{\,p_2} \in \mathfrak{S}(e) \} \cup C\end{equation*}

It is trivial from the Proposition 3.2 that $\varphi(\Gamma,e)$ is defined exactly if e is well-typed under $\Gamma$ .

3.2 Type flow analysis

Type flow analysis is a constraint-solving process. This process is described by an inductive relation $C \vdash \hat T \triangleright_b \hat S \checkmark $ in Figure 6 where C is a set of type flow and $\hat T \triangleright_b \hat S$ is a type flow derived in type flow analysis. The main work of type flow analysis is to decompose type flows by type structure and to recover the data flows mediated via dynamic types. In principle, these rules model value passing and cast generation/elimination happen at runtime.

Fig. 6.

Type flow analysis.

Rule J_Base is the initial situation. Rules J_Fun and J_Rec decompose type flows according to type structures. For a type flow $\hat S_1 \to \hat T_2 \triangleright_b \hat{T}_1 \to \hat{S}_2$ , J_Fun generates type flows for function parameter and return value with respect to their variance. And for a type flow $ \{ \overline{l_i: \hat G_i} \} \triangleright_b \{ \overline{l_j: \hat G_j} \}$ , J_Rec generates type flows for each field l that exists in both $\{ \overline{l_i: G_i} \} $ and $ \{ \overline{l_j: G_j} \}$ .

Rules J_TransDyn and J_Trans resemble cast elimination at runtime. The notation $C \vdash \hat T \triangleright_{b_1} \hat G \triangleright_{b_2} \hat S \checkmark$ is an abbreviation for two hypotheses $C \vdash \hat T \triangleright_{b_1} \hat G \checkmark$ and $C \vdash \hat G \triangleright_{b_2} \hat S \checkmark$ . By intuition, if $\hat T_\star$ is an inflow of a dynamic type $\langle \star, p \rangle$ while $\hat S$ is an outflow of $\langle \star, p \rangle$ , then there is a possible data flow from $\hat T$ to $\hat S$ . Rule J_TransDyn preserves blame label $b_1$ rather than $b_2$ in its conclusion to mirror the evaluation rules in Figure 3. This behavioral mirroring is the key to the correspondence between type flow and type cast proved in Proposition 3.13. If other blame strategies are used (Siek et al., Reference Siek, Garcia and Taha2009), the analysis rules should also be modified to maintain behavioral mirroring.

Rule J_Dummy, on the other hand, expresses ordinary value passing and has nothing to do with the blame mechanism.

The careful reader may wonder why the relation $C \vdash \tau \checkmark$ has no type checks. Actually, there is no need. We say a type flow $\hat{T} \triangleright_\varsigma \hat{S}$ is well-formed if $T <' S$ . Then we can prove the following proposition.

Now we state an algorithm to calculate $C\vdash \tau \checkmark$ .

Let $\mathbb{S}$ be the set of all sub-trees of all labeled type occurs in C, every derived type flow must of the form $\hat{T} \triangleright_\varsigma \hat{S}$ , where $\hat{T},\hat{S} \in \mathbb{S}$ , and $\varsigma$ is either a blame label b occurring in C or just the dummy flag. Since $\mathbb{S}$ and the set of blame labels occurring in C are both finite, the algorithm cannot proceed forever.

3.3 Type flow and type cast

In this section, we show that the type flow analysis on a $\lambda_B$ program e is an overapproximation. More specifically, we will prove that if e is well-typed, then type cast occurring in its evaluation can be derived by type flow analysis.

First, we need some auxiliary definitions.

Suppose that $t = \lambda x:G . (t^{\prime})^{\,p_1}$ , $\Gamma \vdash t^p: G \to T$ , $\overline{\varphi(\Gamma,t^{\,p})} \subseteq \overline{C}$ and $\langle G \to T, p \rangle \triangleright_d \langle G \to T, p'\rangle \in C$ , we will show that $\overline{\varphi(\Gamma,t^{\,p'})} \subseteq \overline{C}$ . Let $\{\overline{x^{\,p_i}}\} = FVO(e,x)$ , $ \overline{\hat{G_i} = \langle G,p_i \rangle}$ , and $\hat{G} = \langle G, p?\rangle, \hat{G'} = \langle G,p'?\rangle, \hat{T} = \langle T, p! \rangle, \hat{T'} = \langle T, p'! \rangle, \hat{T_1} = \langle T, p_1\rangle$ , we know that $\varphi(\Gamma,t^{\,p'}) \setminus \varphi(\Gamma,t^{\,p}) = \{ \overline{ \hat{G'} \triangleright_{d} \hat{G_i} }, \hat{T_1} \triangleright_{d} \hat{T'}\}$ , and $\{ \overline{ \hat{G} \triangleright_{d} \hat{G_i} }, \hat{T_1} \triangleright_{d} \hat{T}\} \subseteq \varphi(\Gamma,t^{\,p}) \subseteq \overline{C}$ . Since $\langle G \to T, p \rangle \triangleright_d \langle G \to T, p'\rangle \in C$ , we have that $\hat{G'} \triangleright_d \hat{G}, \hat{T} \triangleright_d \hat{T'} \in \overline{C}$ by . Then by , $\{ \overline{ \hat{G'} \triangleright_{d} \hat{G_i} }, \hat{T_1} \triangleright_{d} \hat{T'}\} \in \overline{C}$ . So that $\varphi(\Gamma, t^{\,p'}) \subseteq \overline{C}$ , and then $\overline{\varphi(\Gamma, t^{\,p'})} \subseteq \overline{C}$ .

The case where $t = \{\overline{l_i = t_i}\}, (t_1^{\,p_1} t_2^{\,p_2}) , (t^{\,p_1}.l)^{\,p_2}$ or $t =(\mathrm{\texttt{if}}\ e_1\ \mathrm{\texttt{ then}}\ t_2^{\,p_1}\ \mathrm{\texttt{else}}\ t_3^{\,p_2}) $ is similar to lambda case.

Finally, suppose that $t = \langle S \Leftarrow^b T \rangle (t^{\prime})^{\,p_1}$ , then $\varphi(\Gamma,t^{\,p'}) \setminus \varphi(\Gamma,t^{\,p}) = \{ \langle T, p_1 \rangle \triangleright_b \langle S, p' \rangle \}$ . From the hypothesis we know that $\langle S,p \rangle \triangleright_d \langle S, p' \rangle,\langle T, p_1 \rangle \triangleright_b \langle S, p \rangle \in C$ , then by we know that $\langle T, p_1 \rangle \triangleright_b \langle S, p' \rangle \in \overline{C}$ , and the conclusion follows.

Now we can show the dominance relation is preserved under substitution.

Proof Using a simple but somewhat tedious induction, one can show that

(1) \begin{equation} \varphi( \Gamma, (t[x := v])^{\,p}) \setminus \varphi((\Gamma,(x:G)), t^p) = \bigcup_{x^{\,p_i} \in FVO(t^p,x)} \varphi(\Gamma,v^{p_i}) \end{equation}

Therefore we only need to show that for every $x^{\,p_i} \in FVO(t^p,x)$ , $\varphi(\Gamma,v^{p_i}) \subseteq \overline{C}$ . That is, C dominates $v^{p_i}$ under $\Gamma$ . Since C dominates $x^{\,p_i}$ under $\Gamma,(x:G)$ trivially, it follows from lemma 3.11 that C dominates $v^{p_i}$ under $\Gamma,(x:G)$ . Since x is not free in v, $\varphi(\Gamma,v^{p_i}) = \varphi((\Gamma,(x:G)),v^{p_i})$ . Therefore, C also dominates $v^{p_i}$ under $\Gamma$ .

With the substitution lemma, we can show the dominance relation is preserved under single-step reduction.

Our main result is a direct extension.

Suppose that $E = (E_1 t)^{\,p}$ , $E[e] = (E_1[e] t)^{\,p}$ , and $e \longrightarrow s$ . From the inversion lemma, we know that C dominates $E_1[e]$ and t, and from the induction hypothesis we know that C dominates $E_1[s]$ . From F_App, the type preservation lemma and the Lemma 2.10, C also dominates $E[s] = (E_1[s] t)^{\,p}$ . The case that $E = v E_1$ is similar.

Suppose that $E = \{\overline{l_i= v_i^{\,p_i}},l_i= E_1,\overline{l_j= t_j^{\,p_j}}\}$ , $E[e] = E_1[e] t$ , and $e \longrightarrow s$ . From the inversion lemma, we know that C dominates $E_1[e], \overline{v_i^{\,p_i}}, \overline{t_j^{\,p_j}}$ , and from induction hypothesis we know that C dominates $E_1[s]$ . From F_Rec, the type preservation lemma and the Lemma 2.10, C also dominates E[s].

The case that $E = (E_1.l)^{\,p}$ , or $(\mathrm{\texttt{if}}\ E_1\ \mathrm{\texttt{then}}\ e_1 \ \mathrm{\texttt{else}}\ e_2)^{\,p}$ can be analyzed by the same routine.

Suppose that $E = (\langle S \Leftarrow^b T\rangle E_1)^{\,p}$ , $\Gamma \vdash E[e] : G$ , $e \longrightarrow s$ . This case is quite direct, since $\varphi(\Gamma,E_1[s]) \setminus \varphi(\Gamma,E[s]) = \{ \langle T,p \rangle \triangleright_d \langle S,p' \rangle\}$ where p’ is the out-most context label of $E_1[s]$ . However, this type flow is contained in C from the hypothesis and the Lemma 2.10, so C also dominates E[s].

Now the following statement is trivial.

4.1 Normal potential error: Complete

A normal potential error $\langle \star, p \rangle \triangleright_b \hat S$ indicates that a value may flow into an inconsistent context at runtime. Every type flow is monitored by a type cast with the same label, and type safety ensures that every dynamic type error should be caught by a runtime cast. Then a direct corollary of the correspondence is that every dynamic type error should be caught by a normal potential error statically.

We can state this main property of potential type errors formally by blame label:

This theorem, as its name suggests, ensures that every possible blame error can be caught as a normal potential error. On the other hand, a program without any normal potential error will never trigger a blame error. Then the completeness of normal potential error ensures soundness of Static Blame as a software analysis technique.

However, completeness is not enough, we cannot claim that a program with detected normal type flow will necessarily trigger a runtime cast error. That is, detection for normal potential error is not sound. Even if we can assert that no normal potential error can be detected in a completely static program, it would still be a long way from soundness. That is the motivation for strict potential error.

4.2 Strict potential error: Sound up to erroneous casts

A type cast corresponding to a strict potential error is “definitely wrong”. For a strict potential error $\langle \star, p \rangle \triangleright_b \langle S, p_S\rangle$ , its definition requires every inflow of $\langle \star, p \rangle$ to be inconsistent with S. Recall that in Section 2.1, we assume that ty(c) does not contain $\star$ for any constant c. Technically, this assumption serves as the proof for base case of the induction proof for Proposition 3.13. Essentially, it guarantees that constants of type $\star$ do not exist in our system. Therefore, if an expression $t^p$ of type $\star$ is evaluated to a value $v^p$ , v must be an upcast $\langle \star \Leftarrow^{b'} G_\star \rangle (u)^{\,p'}$ . Then by Corollary 3.15, a type flow $\langle G_\star, p \rangle \triangleright_{b'} \langle \star, p \rangle$ can be deduced through type flow analysis. Since $\langle \star, p \rangle \triangleright_b \hat S$ is a strict potential error, we can conclude that $G_\star \not <' S$ and the downcast expression $(\langle S \Leftarrow^{b} \star \rangle t^p)^{\,p_S}$ must fail, as it will be evaluated to $(\langle S \Leftarrow^{b} \star \Leftarrow^{b'} G_\star \rangle (u)^{\,p'})^{\,p_S}$ .

For real-world gradually typed language with constants of type dynamic (i.e., eval ^{Footnote 4} ), further information is required to generate several extra inflow for each possible type of these constants (i.e., a type flow $\hat{\mathrm{\texttt{Int}}} \triangleright_b \hat{\star}$ for eval(“1")). Note that if we simply introduce inflows $\hat{T} \triangleright_{b} \langle \star,p \rangle$ for each type T, it will prevent $\langle \star, p \rangle \triangleright_b \langle S, p_S\rangle$ from being a strict potential error since there will always exist a consistent inflow.

Strict potential errors describe a common mistake programmers make: an item of dynamic type is used incorrectly. It is hard to formally assert a cast is wrong, as we mentioned earlier in Section 1.4. Therefore, we formally define casts that never succeed as erroneous casts and claim that strict potential errors are sound with respect to erroneous casts. Formally, we define erroneous casts as follows:

The definition is straightforward with respect to the semantics of $\lambda_B$ . If a dynamic down-cast $\langle S \Leftarrow^b \star \rangle v$ happens, but the only possible value v is an up-cast $\langle \star \Leftarrow^{b'} T_\star \rangle v'$ from an inconsistent type, then the down-cast must fail after cast elimination.

Formally, erroneous casts are unsafe.

Note that e’ may differ from s’, since e’ may change before cast elimination. To see this, consider the expression $(\lambda x:\star. (\langle Int \Leftarrow^b \star \rangle x)^{\,p}) (\langle \star \Leftarrow^{b'} \mathrm{\texttt{Bool}} \rangle \mathrm{\texttt{False}})$ where most irrelevant context labels omitted. Because the whole expression will reduce to $(\langle Int \Leftarrow^b \star \Leftarrow^{b'} \mathrm{\texttt{Bool}} \rangle \mathrm{\texttt{False}})^{\,p}$ and then abort with a blame message, the sub-expression $(\langle Int \Leftarrow^b \star \rangle x)^{\,p} $ is unsafe but different from $(\langle Int \Leftarrow^b \star \Leftarrow^{b'} \mathrm{\texttt{Bool}} \rangle \mathrm{\texttt{False}})^{\,p}$ .

Then we can formally state that every strict potential error detects an erroneous cast. That is, strict potential error detection is sound with respect to erroneous casts.

4.3 Wrong dynamic types: Values that cannot be used

At last, a wrong dynamic type is a labeled type where every non-dynamic inflow is inconsistent with every non-dynamic outflow. By definition, it is equivalent to saying that every non-dynamic outflow $\langle \star, p \rangle \triangleright_b G_\star$ is a strict potential error. While a strict potential error means a value may be used in a wrong way, the value held in the wrong dynamic type $\langle \star, p \rangle$ can never be used safely as any non-dynamic type. That is why a wrong dynamic type is more severe than a strict potential error.

For example, consider a program:

$(\lambda x:\star. (\lambda y:\star. y + 1) x) \mathrm{\texttt{true}}$

where attached context labels are omitted. If we denote the contexts of parameter x and y by labels $p_1$ and $p_2$ in the compiled program, then type flow analysis will derive $ \mathrm{\texttt{Bool}} \triangleright_{b_1} \langle \star, p_1 \rangle \triangleright_{b_2} \langle \star, p_2 \rangle \triangleright_{b_3} \mathrm{\texttt{Int}}$ . Thus $\langle \star, p_2 \rangle$ is a wrong dynamic type, while $\langle \star, p_1 \rangle$ is not. It may be somewhat counter-intuitive at first glance, as both $\langle \star, p_1 \rangle$ and $\langle \star, p_2 \rangle$ hide the inconsistency between Int and Bool. The design principle of Static Blame is to statically assert properties about a gradually typed language with a given blame mechanism. The result of this program will be $\mathrm{\texttt{blame}}\ b_3$ , that is, projection from $\langle \star, p_2 \rangle$ to Int should be responsible for the dynamic consistency. Both $\langle \langle \star, p_1 \rangle \Leftarrow^{b_1} \mathrm{\texttt{Bool}} \rangle$ and $\langle \langle \star, p_2 \rangle \Leftarrow^{b_2} \langle \star, p_1 \rangle \rangle$ are trivially legal, so $b_1$ and $b_2$ will not be blamed. Since the use of dynamic type value is denoted by a projection at run-time, we assume $\langle \star, p_2 \rangle$ is wrong in keeping with the design principles of the blame mechanism. Formally, we can state the following property.

5.1 Implementation

5.1.1 Static Blame for grift

Grift is a superset of $\lambda_\star$ discussed in this paper. It extends $\lambda_\star$ with several features. In our evaluation of the feasibility of Static Blame, we have selectively supported a significant portion of the commonly used features, including base types (Int, Float, Bool, Unit), operators on base types (e.g., fl+ for float addition.), binding structures (define, let, letrec), iterations (repeat), sequencing (begin), tuples (tuple), and reference types (box, vector) with guarded semantics. While most of these features can be implemented straightforwardly, reference types deserve additional discussion.

Guarded semantics is originally proposed by Herman et al. (Reference Herman, Tomb and Flanagan2010). With guarded semantics, each reference cell access (read and write) will be guarded by a cast between the expected type and the actual type of the reference cell. For example, let r be a reference value of type $\mathrm{\texttt{Ref}}\ \star$ , and i be a value of type Int. Then the cast term $\langle \mathrm{\texttt{Ref}}\ \mathrm{\texttt{Int}} \Leftarrow^b \mathrm{\texttt{Ref}}\ \star \rangle r$ has type $\mathrm{\texttt{Ref}}\ \mathrm{\texttt{Int}}$ . With standard notation of reference types, dereference of this term will generate a downcast:

$!(\langle \mathrm{\texttt{Ref}}\ \mathrm{\texttt{Int}} \Leftarrow^b \mathrm{\texttt{Ref}}\ \star \rangle r) \longrightarrow \langle \mathrm{\texttt{ Int}} \Leftarrow^b \star \rangle (!r)$

while assignments will generate an upcast:

$(\langle \mathrm{\texttt{Ref}}\ \mathrm{\texttt{Int}} \Leftarrow^b \mathrm{\texttt{Ref}}\ \star \rangle r):= i \longrightarrow r := \langle \star \Leftarrow^b \mathrm{\texttt{Int}} \rangle i$

Our implementation supports guarded reference semantics in a direct way. The content of a reference cell is denoted by a new context refinement $\odot$ . And flow analysis is extended by two new rules:

Mutable vector type is supported in a similar manner, where every element of a vector is assumed to have the same labeled type.

5.2 Research questions

We evaluate the effectiveness and performance of SLOG. Specifically, we aim to answer the following two questions:

• • RQ1 (Effectiveness): What is the effectiveness of SLOG? We plan to investigate whether SLOG can detect bugs from Grift programs, as well as the causes of false- positive reports and undetectable bugs.

• • RQ2 (Performance): What is the performance of the Static Blame implementation? Specifically, we plan to investigate its correlation with program size and the proportion of typed code.

Replacing some annotations in a gradually typed program with dynamic types will get another gradually typed program, which is called a configuration of the original program. Therefore, a fully annotated gradually typed program with n type nodes has $2^n$ configurations. Note that, a single type annotation can have multiple type nodes. For example, a type annotation $\mathrm{\texttt{Ref}}\ \mathrm{\texttt{Int}}$ can be “dynamized” into both $\mathrm{\texttt{Ref}}\ \star$ and $\star$ . Consequently, even a small program can have a huge space of configurations.

Configurations are versions of the same program with different proportions of typed code. All configurations of a gradually typed program comprise the migratory lattice of this program. As Takikawa et al. (Reference Takikawa, Feltey, Greenman, New, Vitek and Felleisen2016) observes, the execution of a program may have an overhead of over 100 $\times$ in the worst-case over the entire migratory lattice, much slower than both the fully static version and the fully dynamic version. This observation indicates that the proportion of typed code is a crucial metric for gradually typed programs. Consequently, conducting evaluations of SLOG with varying proportions of typed code is valuable. The evaluation of SLOG involves sampling across the lattice.

5.3 Experimental setup

5.3.1 RQ1: Effectiveness

Ideally, SLOG should be evaluated on a representative collection of programs with runtime cast errors for RQ1. However, there is no such benchmark. Therefore, we take a similar approach to previous work about evaluating blame mechanism (Lazarek et al., Reference Lazarek, Greenman, Felleisen and Dimoulas2021), namely generating a corpus of errors by mutation analysis.

We say that a generated program is a legal scenario or simply scenario if it can be accepted by the Grift compiler. SLOG is evaluated on a collection of legal scenarios. Our approach proceeds as follows, and each step will be described in detail later.

1. 1. Select a representative collection of static programs that: (1) make full use of the various features of the Grift language and (2) vary in size, complexity, and purpose.

2. 2. Inject bugs into these programs with carefully designed mutators. The result programs are called mutants. A mutant is a legal scenario if it can be accepted by the compiler.

3. 3. For each mutant, uniformly sample several programs from its migratory lattice, each sampling result that can be accepted by the compiler is also a legal scenario.

The starting program collection in our experiment is the original benchmark of Grift presented in Kuhlenschmidt et al. (Reference Kuhlenschmidt, Almahallawi and Siek2019). This benchmark consists of eight programs ported from other well-known benchmarks or textbook algorithms for Grift. We chose seven of them as the starting point of mutation analysis. The excluded program sieve uses recursive types not supported by our implementation. The sizes of these chosen programs range from 18 to 221 in terms of LOC, while the numbers of type nodes range from 8 to 280. Details are listed in Table 2.

Table 1.

Summary of mutators

Table 2.

Generated legal scenarios and metrics about source programs

Note: This table shows (1) the numbers of legal scenarios generated by each mutator and each source program after sampling from migratory lattices and (2) two metrics of each source program. The first four rows display legal scenarios, where each row represents a mutator and every column represents a source program. The number N in a cell (M,P) means that there are N legal scenarios in the set of (1) mutants generated by applying M to P along with (2) sampled programs from migratory lattices of these mutants. The last two rows provide two metrics. LOC refers to the Lines Of Code of each program, while NTN represents the Number of Type Nodes of each program.

The mutators we use are inherited from Lazarek et al. (Reference Lazarek, Greenman, Felleisen and Dimoulas2021) with slight changes. The mutators that can successfully generate legal scenarios are described in Table 1. Note that the arithmetic mutator is not a special case of the constant mutator, since operators in Grift are special forms, not constant values. We use only three mutators in the evaluation while Lazarek et al. (Reference Lazarek, Greenman, Felleisen and Dimoulas2021) describe 16 mutators. The main reason is that Lazarek et al. (Reference Lazarek, Greenman, Felleisen and Dimoulas2021) evaluate on the full-fledged language Racket (Flatt & PLT, Reference Flatt2010), while Grift has fewer features. As a result, mutators for some advanced language features are not portable to Grift. For example, Grift does not support classes, and mutators like swapping method identifiers are not portable.

Moreover, the mutators in Table 1 inject additional type ascriptions into programs, while their original version in Lazarek et al. (Reference Lazarek, Greenman, Felleisen and Dimoulas2021) does not. This is because Lazarek et al. (Reference Lazarek, Greenman, Felleisen and Dimoulas2021) processes coarse-grained gradual typing, which means they can hide injected bugs by making the module containing mutations untyped, while we process fine-grained gradual typing, and the injected bug can only be hidden by an explicit annotation. Note that the additional type ascription won’t change the number of configurations in its migratory lattice.

Migratory lattice represents type migration of gradually typed programs, which is the process of making a program more (resp. less) precise by changing the type annotation. Migration of gradually typed programs may change the runtime behavior of a gradually typed program. We also uniformly sample configurations from migratory lattices of mutants. The fully dynamic configuration and the fully static configuration are always chosen as special cases. We use the same sampling algorithm as Kuhlenschmidt et al. (Reference Kuhlenschmidt, Almahallawi and Siek2019) ^{Footnote 8} . It takes a fully typed program, the number of samples, and the number of bins to be uniformly sampled as inputs. These bins partition the migratory lattice by dynamic annotation percentage of configurations in the lattice. And the algorithm will uniformly sample from each bin.

The generated legal scenarios after sampling are shown in Table 2. In summary, we sample 12 scenarios from the migratory lattice of each mutation, and we collect 16,464 legal scenarios by mutation analysis and sampling from migratory lattices.

Recall that a bug in a program is a specific node in the syntax tree of this program. We explicitly give an informal assumption to relate the concepts of bug, bug report, and mutation analysis. Under this assumption, each legal scenario has exactly one bug. We call it actual bug to distinguish it from the SLOG bug reports.

Assumption 1 We assume that every mutant has one bug where the mutation happens. We also assume that an actual bug can be located by a bug report if the report refers to a sub-tree of the actual bug.

Please note that the concept of sub-tree specifically relates to the structure of the Abstract Syntax Tree (AST) in the implementation of the Grift language. This concept is slightly different from sub-expressions formally defined in Definition 2.3. For example, in the case of the let binding $\mathrm{\texttt{let}}\ x\ =\ e_1\ \mathrm{\texttt{in}}\ e_2$ , the sub-tree $x\ =\ e_1$ represents a binding AST node. However, since it is not a valid expression, it is not a sub-expression. In Section 5.5, we provide a discussion on the assumption concerning potential threats to validity.

5.4 Evaluation results and discussion

5.4.1 RQ1: Effectiveness

For RQ1, we run SLOG on every legal scenario and compare the reported bug location(s) with the actual bug location. More specifically, by Assumption 1, we say a bug report (i.e., one output of SLOG for a specific legal scenario) is a true positive if it refers to a sub-tree of the actual bug. For each legal scenario, we run SLOG three times, each time restricting SLOG to a different category of potential error. Therefore, there will be three categories of bug reports for each scenario.

The result of our evaluation is shown in Table 3. The precision is the rate of true positives in all bug reports. The recall is the rate of scenarios with any true positives among all scenarios. Intuitively, precision reflects how many reports are correct, while recall reflects how many actual bugs can be found by the SLOG. Overall, the relative relationship of precision rates is as we expected from the theory. Normal potential errors are the least precise, strict potential errors are more precise, and wrong dynamic types are the most precise. Accordingly, their recall rates also decrease in this order.

Table 3.

Effectiveness evaluation of SLOG

NPE: Normal Potential Errors. SPE: Strict Potential Errors. WDT: Wrong Dynamic Types.

Note: This table shows the evaluation result in terms of the categories of our classification of errors. The column #Rep gives the number of bug reports among all legal scenarios. The column TP gives the number of true positives among these reports. The column #TSce gives the number of scenarios with any true positive reports. That is the number of detectable actual bugs. The precision is calculated by $\mathrm{TP}/\mathrm{\#Rep}$ , while the recall is the ratio of #TSce among all 16464 scenarios. Erecall is the recall of the dataset after removing non-type scenarios.

We delve into two issues: why SLOG detects false bugs and why certain bugs remain undetected. Therefore, we manually classify 1) the false-positive reports and 2) scenarios without any true-positive report. The theoretical nature of normal potential error, its similarity to strict potential error, and its low precision make it less interesting. Therefore, we only analyze strict potential error and wrong dynamic type.

Specifically, we manually classified all false-positive reports consisting of 1049 strict potential error reports and 655 wrong dynamic type reports. For scenarios without any true positive report, the classification procedure is conducted on two distinct samples.

The first sample comprises 371 scenarios without strict potential error reports, while the second sample comprises 372 scenarios without wrong dynamic type reports. Both samples exhibit a confidence level of 95% and a margin of error that does not exceed 5%. The sample size is calculated using calculator.net. The result of classification is listed in Table 4. We now explain each category in detail.

Table 4.

Cause of false positives and false negatives

Note: This table shows our results of manual classification. Table Fp-cause shows the classification of false positive reports, while table NoTp-cause shows the classification of scenarios without true positive reports. That is the classification of reasons for undetectable bugs. Column SPE represents strict potential errors and WDT for wrong dynamic types.

The causes of false positives include Escape (ESC), Refinement (REF), and Implementation (IMP).

Escape (ESC) happens when a dynamically typed variable is assigned a value of a certain type but incorrectly used as another inconsistent type. For example, the following code assigns an integer to a variable x, and each use of x as an integer is an escape of strict potential errors.

(1)

If we view the syntax node $x\ :\ \star\ =\ 1.0$ as a bug (since replacing $1.0$ by 1 will fix it), then every cast inserted in the let-body that converts x from dynamic type to integer will result in a false positive of strict potential errors. Because the blame labels of these casts will refer to the use rather than the initial assignment $x\ :\ \star\ =\ 1.0$ .

This example does not result in false positives of wrong dynamic types since each use of x will have the same labeled type. However, when the value of x is assigned to another dynamically typed variable, the escape of wrong dynamic types also occurs.

(2)

In the Example 2, the dynamic type of y rather than x will be the wrong dynamic type reported since each use of y is an outflow of y rather than x. Similarly, if we still view the syntax node $x\ :\ \star\ =\ 1.0$ as a bug, a false positive occurs.

The Escape phenomenon exposes a fundamental limitation of Static Blame. In the absence of prior knowledge, distinguishing whether an assignment or use is a bug becomes challenging. For instance, in Example 2, it is unclear whether a floating-point variable is being improperly used as an integer variable or if a floating-point value is mistakenly passed into an integer variable. While escape problems can be solved simply by adding type annotations, they can also be addressed by tracking both the use and assignment without necessitating additional type annotations. Unfortunately, the current label tracking mechanism of Static Blame lacks this capability. As part of our future work, we aim to address this limitation.

Refinement (Ref) happens when a potential error is associated with a portion of a value of a composite type. The situation is slightly different between strict potential errors and wrong dynamic types. The following code assigns a pair of two floating-point values to a dynamically typed variable, which is used inconsistently as a pair of an integer and a floating-point.

(3)

While the “real” location is the sub-expression $(2.0\ :: \ \star)$ , SLOG will report the outer pair expression $\langle (2.0\ :: \ \star), 1.0 \rangle$ . For strict potential errors, the relevant cast $\langle Int \Leftarrow^b \star \rangle$ is decomposed from a larger cast $\langle Int \times Float \Leftarrow^b \star \rangle$ which will refer to the outer pair expression. For wrong dynamic types, recall that we only use the program label in mapping, while all context refinements are abandoned. Therefore, it can only refer to the outer pair expression.

In our experiment, the location (a syntax tree node) of the false-positive report caused by REF is always the direct parent of the actual bug. Although not in accordance with our Assumption 1, during the classification process we can always find the actual bug directly from the false positive report caused by REF.

Implementation (IMP) is due to a bug ^{Footnote 9} in the Grift compiler itself, the source location information attached to syntax tree nodes is shifted on the first sub-tree of all binding constructs. A false-positive report is classified as IMP if it can be eliminated by fixing this issue.

Among all 1049 false-positive reports of wrong dynamic types, 1020 are due to ESC, 19 are due to REF, and 10 are due to IMP. Among all 655 false-positive reports of strict potential error, 472 are due to ESC, 119 are due to REF, and 64 are due to IMP.

The causes of bugs that cannot be found include non-type (NTY), smashing abstraction(SMASH), and transition (TRAN). The implementation issue mentioned above (IMP) can also make a bug undetectable. Similarly, a scenario is classified as IMP if it can be eliminated by fixing this issue.

Non-type (NTY) means that a scenario does not involve a type-related bug. This category accounts for the vast majority of causes of undetectable bugs. We also estimated the recall of SLOG after removing NTY from all scenarios, noted in Table 3 as column ERecall. We list the two found NTY patterns here.

1. 1. Modifying arithmetic results without affecting the type. An example of this is exchanging the definitions of two variables of the same type.

2. 2. Not altering the program’s semantics. An example of this is exchanging two arguments of the operator “+” while maintaining the same meaning.

Transition (TRAN) is analogous to the escape problem in principle, although it leads to different results. Consider a simple lambda expression that adds 1 to its dynamically typed parameter x and returns the result. If all actual arguments are inconsistent with integer, then the parameter type $\star$ is a wrong dynamic type, and the use of x in the lambda body will be caught as a strict potential error.

(4)

However, if some actual arguments are inconsistent with integer but others are consistent, then both wrong dynamic errors and strict potential errors will disappear.

(5)

This is because, in our definition, an outflow is treated as a strict potential error only if it is inconsistent with all inflows. And wrong dynamic type is defined via strict potential errors. Therefore, a dynamically typed variable cannot be reported as a bug by strict potential errors or wrong dynamic types as long as some of its uses are correct. Thus, TRAN is a trade-off for the increased precision of strict potential error and wrong dynamic type.

Smashing abstraction (SMASH) stems from our smashing abstraction of vectors and tuples. In this model, all elements of a vector or tuple are treated as a single element (Blanchet et al., Reference Blanchet, Cousot, Cousot, Feret, Mauborgne, Miné, Monniaux and Rival2002). For example, consider a vector of type $\mathrm{\texttt{Vec}}\ \mathrm{\texttt{Int}}$ , one component $(1.0\ :: \star)$ has an inconsistent type, but the other components are normally assigned values of type Int. SLOG treats the vector as having only one component, and thus cannot detect potential errors. Therefore, the smashing abstraction stands as one of the inherent shortcomings of Static Blame.

Among all 371 scenarios without strict potential error reports, 352 are due to NTY, 13 are due to TRAN, and 6 are due to SMASH. Among all 372 scenarios without any wrong dynamic type report, 345 are due to NTY, 18 are due to TRAN, 5 are due to SMASH, and 4 are due to IMP.

Overall, we answer RQ1 by concluding that SLOG is able to detect bugs from Grift programs.

5.4.2 RQ2:Performance

For RQ2, Figure 7 shows the results of SLOG on Size, and Figure 8 shows the results of SLOG on Lattice. Recall that Size is a collection where programs increase linearly in size, while Lattice is a collection of 1000 configurations of the same program.

Fig. 7.

SLOG performance with respect to program size.

Fig. 8.

SLOG performance with respect to the proportion of typed code.

Across the nine measured programs in Size, the run time exhibits quadratic growth with respect to program size. To make it clear, we also record the increment between adjacent points in Figure 7, whose growth is almost linear. In Figure 7, each point in the blue line represents one program in the collection Size, which is created by repeating code in the ray program. The horizontal coordinate of a point is the LOC of this program, while the vertical coordinate is the run time of SLOG. The cyan line records the increment between the adjacent points of the blue line. It has been observed that the performance of SLOG is impacted by the size of the program. The quadratic growth rate is acceptable for relatively small and medium programs. However, its efficiency diminishes when dealing with larger programs.

Figure 8 depicts the variation in SLOG performance in relation to the percentage of typed code. Each point represents one program in the collection Lattice. The horizontal coordinate of a point is the proportion of typed code in this program, while the vertical coordinate is the run time of this program. Figure 8 shows that there is no significant relationship between performance and the proportion of typed code in most cases. However, as the program approaches fully typed, there is a significant increase in the run time of SLOG. In other words, the more precise the type annotations in the program, the slower SLOG runs. This fact may be surprising at first sight because a more precise program should be easier to “check”.

To explain this significant increase more clearly, we also record the number of type flows generated by SLOG in Figure 9. The type flow analysis of Static Blame detects potential errors by continuously traversing the set of type flows and generating new type flows. Therefore, the monotonically increasing set of type flows is the main and necessary cause of the runtime efficiency of SLOG.

Fig. 9.

Number of type flows with respect to the proportion of type annotation.

In Figure 9, each data point represents a single program in the Lattice collection. The first sub-figure displays the total number of type flows generated by each program. The horizontal coordinate of a point is the type annotation proportion of the program, while the vertical coordinate is the number of type flows. The first sub-figure of Figure 9 shows the total number of generated type flows increases rapidly as the program approaches fully typed and exhibits the same phenomenon as run time. This indicates that the growth of runtime can be explained by the increase in type flows, as anticipated. To elucidate this phenomenon, we present the second sub-figure, which delves into the underlying reasons for this growth of type flows.

Each point in the second sub-figure is still a program in the Lattice collection. The color represents the proportion of type annotation for each program. The horizontal coordinate of each point is the proportion of dummy type flows among all type flows, while the vertical coordinate of each point still shows the total number of type flows.

The second sub-figure shows the fact that most of the type flows generated are dummy type flows when the program approaches fully static. Therefore, the increase in the number of dummy type flows is the main reason for the rise in run time.

This phenomenon illustrates two points. First, it is very expensive to compute the value passing relations according to Static Blame. Second, the dynamic types in the program “block” further analysis, which greatly reduces the cost of computation of Static Blame.

Overall, we answer RQ2 by concluding that the performance of SLOG is acceptable for programs of small and medium sizes within two or three thousand lines of code. In particular, the run time is quadratic in the size of the program, and the generation of type flows during value passing analysis is the main performance burden.

5.5 Threats to validity

One concern with these experiments is the representativeness of generated bugs. This threat has two aspects: (1) Grift is a simple academic language without many language features and thus a limited set of possible kinds of bugs and (2) the mutation analysis is a coarse approximation of the bugs in real-world programming. Therefore, the experiment may not uncover certain shortcomings of Static Blame.

For instance, our algorithm is unable to handle primitive operators with dynamic types, which is common in gradually typed languages other than Grift (e.g. range in Reticulated Python) and is more challenging to detect statically. However, it is worth noting that these operators are not involved in the benchmark either. Furthermore, the marginal decrease in recall presented in Table 3 also suggests that the bugs injected through mutation may be overly simplistic to detect.

Another concern is the experimental design. Considering that different bugs may influence each other, there is merely one bug per scenario, and therefore do not fully reflect real-world programming, where there may be multiple bugs in a program. Moreover, when the bug code becomes more complex, it becomes more difficult to locate the entire bug from one of its fragments.

The Assumption 1 might not always remain valid. A significant issue arises when the reported bug represents a considerably deep sub-tree of the actual bug. In such cases, the process of locating the actual bug may still require a substantial amount of time. However, in our experiment, almost all bug reports classified as true positives are either the exact bug itself or direct children or grandchildren of the bug, indicating a shallow depth. Consequently, the impact of Assumption 1 on the experiment’s conclusion is minimal, at least within the scope of our experiment.

6.1 Static analysis for gradual typing

Static analysis for gradually typed languages is a relatively unexplored field. Many of the related work focuses on how to optimize the performance of gradually typed language.

6.2 Blame mechanism

The blame mechanism in gradually typed languages comes from the study of high-order contracts (Findler & Felleisen, Reference Findler and Felleisen2002), where type annotations can be considered a kind of contract. Academically, the blame mechanism is a tool for characterizing program behavior in the absence of type safety. Wadler and Findler (Reference Wadler and Findler2009) use a number of subtyping relations to formalize and prove a slogan that well-typed components cannot be blamed, i.e., if a cast fails at runtime it must blame the more imprecise side of the cast. It can be viewed as a complete method for finding error casts statically. Our search for normal potential errors is also a complete method, but slightly more precise because we analyze the program globally rather than just comparing type precision for every cast. Blame mechanism is also an important characterization tool of the well-known criteria for gradual typing proposed by Siek et al. (Reference Siek, Vitousek, Cimini, Tobin-Hochstadt and Garcia2015), which also became the subsequent design guidelines for gradually typed languages (Garcia et al., Reference Garcia, Clark and Tanter2016; Igarashi et al., Reference Igarashi, Sekiyama and Igarashi2017).

Practically, the blame mechanism is designed to help programmers debug runtime type errors. However, there are few industrial languages implementing blame mechanism. The most popular languages that combine dynamic and static typing do not perform any checks at runtime, like TypeScript et al. This is partly because of the large runtime overhead associated with dynamic checks and partly because the effectiveness of blame is questionable. Lazarek et al. (Reference Lazarek, Greenman, Felleisen and Dimoulas2021) evaluate the usefulness of the blame mechanism for debugging by mutation analysis and conclude that blame information can only help in a slight margin. Greenman et al. (Reference Greenman, Felleisen and Dimoulas2019) theoretically prove the effectiveness of a more accurate blame mechanism by adapting complete monitoring to gradual typing.

6.3 Different semantics and extension of gradual typing

Our work relies heavily on cast semantics, while gradual typing has many different semantics. The transient semantics (Vitousek et al., Reference Vitousek, Kent, Siek and Baker2014) is proposed to get better performance at the cost of sacrificing precision since the general cast semantics has performance problems (Takikawa et al., Reference Takikawa, Feltey, Greenman, New, Vitek and Felleisen2016). Concrete Semantics (Wrigstad et al., Reference Wrigstad, Nardelli, Lebresne, Östlund and Vitek2010; Muehlboeck & Tate, Reference Muehlboeck and Tate2017; Richards et al., Reference Richards, Nardelli and Vitek2015; Lu et al., Reference Lu, Greenman, Meyer, Viehland, Panse and Krishnamurthi2022), on the other hand, maintains additional type information for each value, optimizing the performance of gradual typing at the cost of expressiveness. In addition, gradual typing has many different strategies for handling memory, such as the guarded reference (Herman et al., Reference Herman, Tomb and Flanagan2010) which is the semantics supported by our implementation on Grift; the monotonic reference (Siek et al., Reference Siek, Vitousek, Cimini, Tobin-Hochstadt and Garcia2015) and the AGT-induced semantics (Toro & Tanter, Reference Toro and Tanter2020). Therefore, exploring how to establish a correlation between type flow and these semantics is important for future work.

The concept of context labels shares some similarities with the concept of tags in Vitousek et al. (Reference Vitousek, Swords and Siek2017), which also defines a concept “labeled type”. However, the usage and definition of these concepts differ significantly. In Vitousek et al. (Reference Vitousek, Swords and Siek2017), a labeled type is simply a compiled type cast. Let $\langle T \Leftarrow^b S \rangle$ be a type cast, the labeled type $[\![ \langle T \Leftarrow^b S \rangle ]\!]$ it compiles to encodes two kinds of information:

1. 1. The blame label b is associated with the type cast.

2. 2. For each element in the type structure, whether or not the type cast is responsible for introducing that specific portion of type.

For example, $[\![ \langle \star \to \mathrm{\texttt{int}} \Leftarrow^b \mathrm{\texttt{int}} \to \mathrm{\texttt{int}} \rangle ]\!] = \mathrm{\texttt{int}}^b \to^\epsilon \mathrm{\texttt{int}}^\epsilon$ . This cast is responsible for introducing the argument type $\star$ , and any check failure caused by non-int arguments should blame this cast. Therefore, there is a blame label b in the argument position of the labeled type. Tags (ARG, RES,…) are used to locate specific portion in labeled types. In conclusion, labeled types and tags serve to store and query blame information in Vitousek et al. (Reference Vitousek, Swords and Siek2017).

However, while Vitousek et al. (Reference Vitousek, Swords and Siek2017) focuses on designing gradual typing semantics, this paper concentrates on static analysis. Context labels in our work are utilized to identify and track the evaluation of expressions in the source codes. Technically, context labels in our work do not affect program execution and are mainly used to generate unique names in analysis.

The potential error that Static Blame focuses on is caused by imprecision in gradual types. Some related work attempts to increase the precision of gradual types while preserving flexibility. Toro and Tanter (Reference Toro and Tanter2017) devise gradual union types, combining tagged and untagged concatenation types using the AGT approach. Castagna et al. (Reference Castagna, Lanvin, Petrucciani and Siek2019) combine set-theoretic types with gradual types. They map gradual types to sets of types, thus providing a semantic interpretation of gradual types. These extensions improve the expressiveness of the type system, and programmers can thus allow the type system to statically rule out potential errors by avoiding the use of dynamic types. However, this type of work is orthogonal to Static Blame. Dynamic types are still allowed to exist in these systems, and explicitly annotated dynamic types will still hide problematic data flows.