2.1 Review: Algebraic effects and handlers

Algebraic effects and handlers (Plotkin and Pretnar, Reference Plotkin and Pretnar2009, Reference Plotkin and Pretnar2013) are a mechanism that enables users to define their own effects. They are successfully able to separate the syntax and semantics of effects. The syntax of an effect is given by a set of operations, which are used to trigger the effect. For example, exception is triggered by the operation raise and store manipulation is triggered by put and get, which are used to write to and read from, respectively, a store. The semantics is given by handlers, which decide how to interpret operations performed by effectful computation.

Our running example is nondeterministic computation which enumerates all of the possible outcomes (Plotkin and Pretnar, Reference Plotkin and Pretnar2009, Reference Plotkin and Pretnar2013). This computation utilizes two operations: select, which chooses an element from a given list, and fail, which signals that the current control flow is undesired and the computation should abort. ^{Footnote 4} For simplicity, we fix the list element type to be the type int of integers here; the polymorphic version shall be discussed in Section 2.2.

For example, consider an implementation of a filtering function using these operations:

The first two lines declare the operations select and fail, which have the type signatures int list $\hookrightarrow$ int and unit $\hookrightarrow$ unit, respectively. A type signature $ A \hookrightarrow B $ of an operation signifies that the operation is called with an argument of type A and, when the control gets back to the caller, it receives a value of B. We refer to A and B as the parameter type and arity type, respectively (Plotkin and Pretnar, Reference Plotkin and Pretnar2008).

The function filter in Lines 4–12 operates select and fail to filter out the elements of a list l that do not meet a given predicate f. Now, let’s take a closer look at the body of the function, which consists of a single handle–with expression of the form handle M with H. This expression installs a handler H during the evaluation of M, which we refer to as the handled expression.

The handled expression (Lines 6–8) chooses an integer selected from the list l by calling select, tests whether the selected integer x satisfies f, and returns x if f x is true; otherwise, it aborts the computation by calling fail. We write $ {\textrm{#}} \mathsf{op} {(} {M} {)} $ to call operation $\mathsf{op}$ with argument M. We now explain the handler in Lines 10–12, which collects all the values in l that satisfy f as a list, along with an intuitive meaning of handle–with expressions.

The handler H in handle M with H consists of a single return clause and zero or more operation clauses. The return clause takes the form return x $\rightarrow$ M and computes the entire result M of the handle–with expression using the value of the handled expression, which M refers to by x. For example, the return clause in this example is return z $\rightarrow$ [z]. Because z will be bound to the result of the handled expression x, the entire result is the singleton list consisting of x. An operation clause of the form op x $\rightarrow$ M for an operation op decides how to interpret the operation op called by the handled expression. Variable x will be bound to the argument of the call to op and M is the entire result of the handle–with expression. For example, the operation clause fail z $\rightarrow$ [ $\,$ ] means that, if fail is called, the computation is aborted—similarly to exception handling—and the entire handle–with expression returns the empty list, meaning that there is no result satisfying f.

Unlike exception handling, which discards the continuation of where an exception is raised, handlers can resume computation from the point at which the operation was called. The ability to resume a computation suspended by the operation call provides algebraic effects and handlers with the expressive power to implement control effects (Bauer and Pretnar, Reference Bauer and Pretnar2015; Leijen, Reference Leijen2017; Forster et al., Reference Forster, Kammar, Lindley and Pretnar2019). In our language, we use the expression resume M to resume the computation of the handled expression with the value of M.

The operation clause for select enumerates all the possible outcomes by using resume. The clause first resumes the computation from the point at which select was called, with each integer y of a given list l as a return value of the call to select. The handled expression in the example calls select only once, so each resumed computation (which is performed under the same handler ^{Footnote 5} ) returns either a singleton list (produced by the return clause) or the empty list (produced by the clause for fail). The next step after the completion of all the resumed computations is to concatenate their results. The two steps are expressed by concat (map l ( $\lambda$ y. resume y)), where the function concat concatenates a list of lists and map returns a new list obtained by applying a given function to each element of a given list.

More formally, the suspended computation is expressed as a delimited continuation (Felleisen, Reference Felleisen1988; Danvy and Filinski, Reference Danvy and Filinski1990), and resume simply invokes it. For example, let us consider evaluating in the last line. This reduces to the following expression:

where H denotes the same handler as that in the example. At the call to select, the run-time system constructs the following delimited continuation c

(where [] is the hole to be filled with a resumption argument), and then evaluates the operation clause for select. The resumption expression in the operation clause invokes the delimited continuation c after filling the hole with an integer in the list [3; 5; 10]. For the case of filling the hole with 3, the remaining computation c[3] to resume is:

Because 3 is an odd number, it satisfies the predicate ( $\lambda$ x. x mod 2 = 1), and therefore the final result of this computation is the singleton list [3]. The case of 5 behaves similarly and produces [5]. In the case of 10, because the even number 10 does not meet the given predicate, the remaining computation $c[\texttt{10}]$ would call fail and, from the operation clause for fail, the final result of $c[\texttt{10}]$ would be the empty list. The operation clause for select concatenates all of these resulting lists of the resumptions and finally returns [3; 5]. This is the behavior that we expect of filter exactly.

The handler in the example works even when select is called more than once, e.g.:

This program returns a list of the values of the handled expression that are computed with $(\texttt{x}, \texttt{y}) \in \{ \texttt{2}, \texttt{3} \} \times \{\texttt{10}, \texttt{20} \} $ such that the multiplication x * y does not exceed 50.

Typechecking.

We also review the procedure to typecheck an operation clause op x $\rightarrow$ M for op of type signature $A \hookrightarrow B$ . Since the operation op is called with an argument of A, the typechecking assigns type A to argument variable x. As the value of M is the result of the entire handle–with expression, the typechecking checks M to have the same type as the other clauses including the return clause. The typechecking of resumption expressions resume M’ is performed as follows. Since the value of M’ will be used as a result of calling op in a handled expression, M’ has to be of the type B, the arity type of the operation op. On the other hand, since the resumption expression returns the evaluation result of the entire handle–with expression, the typechecking assumes it to have the same type as all of the clauses in the handler.

For example, let us consider the typechecking of the operation clause for select in the function filter. Since the type signature of select is int list $\hookrightarrow$ int, the variable l is assigned the type int list. Here, we suppose map and concat to have the following types:

(these types can be inferred automatically). The type of map requires that the arguments l and have the types int list and int $\rightarrow$ int list, respectively, and they do indeed. The requirement for l is met by the type assigned to l. We can derive that has type int $\rightarrow$ int list as follows: first, the typechecking assigns the bound variable y type int and checks resume y to have int list. An argument of a resumption expression has to be of the type int, which is the arity type of select, and y has that type indeed. Then, the typechecking assumes that resume y has the same type as the clauses of the handler, which is the type int list. Thus, $\lambda$ y.resume y has the desired type.

2.2 Polymorphic effects

Polymorphic effects are a particular kind of effects that incorporate polymorphism,^{Footnote 6} providing a set of operations with polymorphic type signatures. We also call such operations polymorphic.

We write a polymorphic type signature as $ \forall \alpha_{{\mathrm{1}}} . \, ... \, \forall \alpha_{{n}} . \, A \hookrightarrow B $ , which quantifies the type variables $\alpha_{{\mathrm{1}}} \dots \alpha_{{n}}$ occurring in the parameter type A and those in the arity type B. To avoid ambiguity, we denote a type signature with a polymorphic parameter type $ \forall \, \alpha {.} \, A$ by $ {(} \forall \, \alpha {.} \, A {)} \hookrightarrow B $ .

For example, we can assign select and fail polymorphic signatures and write the program as follows:

This program evaluates to the list [2; 3; 20] (30 is filtered out by the call to fail).

Polymorphic type signatures enable operation calls with arguments of different types. For example, #select([2; 3]) and #select([true; false]) are legal operation calls that instantiate the bound type variable $\alpha$ of the type signature with int and bool, respectively. The calls to the same operation are handled by the same operation clause, even if the calls involve different type instantiations. It is also interesting to see that the use of polymorphic type signatures makes programs more natural and succinct: Thanks to its polymorphic arity type, a call to fail can be put anywhere, making it possible to put x in the else-branch, unlike the monomorphic case in Section 2.1.

Another benefit of polymorphic type signatures is that they contribute to the exclusion of undesired operation implementations. For example, the polymorphic signature of fail ensures that, once we call fail, the control never gets back and that of select ensures that no other values than elements in an argument list are chosen. Parametricity (Reynolds, Reference Reynolds1983) enables formal reasoning for this; readers are referred to Biernacki et al. (Reference Biernacki, Piróg, Polesiuk and Sieczkowski2020) for parametricity with the support for polymorphic algebraic effects and handlers.

2.3 Naive polymorphic typechecking is unsound

Naive typechecking of operation clauses for polymorphic operations is obtained by extending the monomorphic setting. The only difference is that the operation clauses have to abstract over types. Namely, an operation clause op x $\rightarrow$ M for op of polymorphic type signature $\forall \alpha.\, A\hookrightarrow B$ is typechecked as follows. The typechecking process allocates a fresh type variable $\alpha$ , which is bound in M, and assigns type A (which may refer to the bound type variable $\alpha$ ) to variable x. Resumption expressions resume M’ in M are typechecked as in the monomorphic setting; that is, the typechecking checks M’ to be of B (which may refer to $\alpha$ ) and assumes the resumption expressions to have the same type as the clauses in the handler. Finally, the typechecking checks whether M is of the same type as the other clauses in the handler. It is easy to see that the polymorphic versions of the select and fail example typecheck.

However, this naive extension is unsound under unrestricted polymorphic type assignment. In what follows, we revisit the counterexample given by Sekiyama and Igarashi (Reference Sekiyama and Igarashi2019), which is an analogue to that found by Harper and Lillibridge (Reference Harper and Lillibridge1993, Reference Harper and Lillibridge1991) for call/cc (Clinger et al., Reference Clinger, Friedman, Wand, Nivat and Reynolds1985).

We first check that this program is well typed. The handled expression first binds the variable f to the result returned by get_id. In polymorphic type assignment, we can assign a polymorphic type $\forall \alpha.\,\alpha \rightarrow \alpha$ to f by allocating a fresh type variable $\alpha$ , instantiating the type signature of get_id with $\alpha$ , and generalizing $\alpha$ finally. The polymorphic type of f allows viewing f both as a function of the type bool $\rightarrow$ bool and of the type int $\rightarrow$ int. Thus, the handled expression is well typed. Turning to the operation clause, since the type signature of get_id is $\forall \alpha.$ unit $\hookrightarrow (\alpha \rightarrow \alpha)$ , typechecking first allocates a fresh type variable $\alpha$ and assigns the type unit to the argument variable x. The signature also requires the arguments of the resumption expressions to have the type $\alpha \rightarrow \alpha$ , and both arguments $\lambda$ z1. $...$ z1 and $\lambda$ z2. z1 do indeed. The latter function is typed at $\alpha\rightarrow \alpha$ because the requirement for the former ensures that z1 has $\alpha$ . Thus, the entire program is well typed.

However, this program gets stuck. The evaluation starts with the call to get_id in the handled expression. It constructs the following delimited continuation:

The run-time system then replaces the resumption expressions with the invocation of the delimited continuation. Namely, the entire program evaluates to

The evaluation of M proceeds as follows.

Subsequently, the term is to be evaluated. The delimited continuation c expects the hole to be filled with a polymorphic function of $\forall \alpha.\, \alpha \rightarrow\alpha$ but the function is not polymorphic. As a result, the term gets stuck:

A standard approach to this problem is to restrict operation calls in polymorphic expressions (Tofte, Reference Tofte1990; Leroy and Weis, Reference Leroy and Weis1991; Appel and MacQueen, Reference Appel and MacQueen1991; Hoang et al., Reference Hoang, Mitchell and Viswanathan1993; Wright, Reference Wright1995; Garrigue, Reference Garrigue2004; Asai and Kameyama, Reference Asai and Kameyama2007). While this kind of approach prevents #get_id() from having a polymorphic type, it disallows calls to any polymorphic operation inside polymorphic expressions even when the calls are safe; interested readers can be referred to Sekiyama and Igarashi (Reference Sekiyama and Igarashi2019) for further discussion. Sekiyama and Igarashi (Reference Sekiyama and Igarashi2019) have proposed a complementary approach to this problem, that is, restricting, by typing, the handler of a polymorphic operation, instead of restricting handled expressions. While this approach allows polymorphic expressions to use any polymorphic effect, it requires all effect handlers to meet the proposed typing discipline. That is, effects implemented with effect handlers violating the discipline cannot be used anywhere—even in monomorphic contexts, although the use of polymorphic effects in such contexts should be safe (Tofte, Reference Tofte1990).

2.4 Our work: Signature restriction

This work takes a new approach to ensuring the safety of any call of an operation. Instead of restricting how it is used or implemented, we restrict its type signature: An operation op : $\forall \alpha.\, A \hookrightarrow B$ should not have a “bad” occurrence of $\alpha$ in A or B. We refer to this restriction as signature restriction.

To see how the signature restriction works, let us explain why type preservation is not easy to prove with the following example, where type abstraction $\Lambda \beta.\, M$ and type application $M\{A\}$ are explicit for the ease of readability:

Here, we suppose the type signature of op to be $\forall \alpha.\, A\hookrightarrow B$ . Notice that the type variable $\alpha$ in the signature $\forall \alpha.\, A \hookrightarrow B$ is instantiated to $\beta$ , which is locally bound by $\Lambda \beta$ . Handling of operation op constructs the following delimited continuation:

The problem is that an appropriate type cannot be assigned to it under the typing context of the handler H: the type of the hole should be $B[\beta/\alpha]$ , but the type variable $\beta$ is not in the scope of H. This is a kind of scope extrusion. We have focused on the scope extrusion via the continuation, but the operation argument v may cause a similar problem when its type $A[\beta/\alpha]$ contains the type variable $\beta$ .

This analysis suggests that polymorphic operations instantiated with closed types, i.e., types without free type variables (especially $\beta$ here), are safe to be performed because then the types of the hole and the operation argument should not contain $\beta$ and, thus, the continuation and the argument could be typed under the typing context of H. ^{Footnote 7} However, allowing only instantiation with closed types is too restrictive. For example, it even disallows a function $\lambda x.\,$ #select(x) wrapping select to have a polymorphic type $\forall \alpha.\,\alpha \, \texttt{list} \rightarrow \alpha$ because, for the function to have this type, the bound type variable of the type signature of select has to be instantiated with a non-closed type $\alpha$ .

As another solution to the scope extrusion, we introduce strong signature restriction, which requires that, for each polymorphic operation op : $\forall \alpha.\, A \hookrightarrow B$ , the type variable $\alpha$ occur only negatively in A and only positively in B. This is a sufficient condition to prove type preservation. Consider, for example, the expression

where v is a value and C is a type with free type variables $\beta_1, \dots, \beta_n$ . The idea is to rewrite this expression, immediately before the call of op, to

(where the rewritten part is shaded). In $M_1'$ , because the type variable $\alpha$ in op : $\forall \alpha.\, A \hookrightarrow B$ is instantiated with a closed type $\forall \beta_1 \dots \beta_n.\, C$ , this operation call should be safe provided that $M_1'$ is well typed. This expression is indeed typable if the strong signature restriction is enforced, as seen below. To ensure that $M_1'$ is typable, we need to have

To this end, we employ type containment (Mitchell, Reference Mitchell1988), which is also known as “subtyping for second-order types” (Tiuryn and Urzyczyn, Reference Tiuryn and Urzyczyn1996). Type containment $ \sqsubseteq $ accepts the following key judgments:

\begin{align*} A[C/\alpha] & \sqsubseteq A[\forall \beta_1 \dots \beta_n.\,C/\alpha] \\ B[\forall \beta_1 \dots \beta_n.\,C/\alpha] & \sqsubseteq B[C/\alpha]\ ,\end{align*}

which follow from the acceptance of type instantiation $(\forall \beta_1 \dots \beta_n.\,C) \sqsubseteq C$ and the strong signature restriction which assumes that $\alpha$ occurs only negatively in A and only positively in B. Since $M_1$ is typable, we have $v : A[C/\alpha]$ and, by subsumption, $v : A[\forall \beta_1 \dots \beta_n.\,C/\alpha]$ . Therefore, the operation #op $\{\forall \beta_1 \dots \beta_n.\, C\}$ is applicable to v and we have #op $\{\forall \beta_1 \dots \beta_n.\, C\}$ (v) ${}: B[\forall \beta_1 \dots \beta_n.\,C/\alpha]$ . Again, by subsumption, #op $\{\forall \beta_1 \dots \beta_n.\, C\}$ (v) ${}: B[C/\alpha]$ as desired. Therefore, $M_1'$ is also typable. Note that the translation from $M_1$ to $M_1'$ does not change the underlying untyped term, but only the types of (sub)expressions; hence, if $M'_1$ does not get stuck, neither does $M_1$ .

However, the strong signature restriction is still unsatisfactory in that the type signatures of many operations do not conform to it. For example, the signature of select : $\forall \alpha.\, \alpha \, \texttt{list} \hookrightarrow \alpha$ in Section 2.2 does not satisfy the requirement of the strong signature restriction, which disallows the positive occurrences of bound type variables in parameter types (the left-hand side of $\hookrightarrow$ ).

Signature restriction is a relaxation of the strong signature restriction, allowing the type variable $\alpha$ in the signature $\forall \alpha.\, A \hookrightarrow B$ to occur at strictly positive positions in A in addition to negative positions. The proof of type preservation in this generalized case is essentially the same

as above but two changes. First, we close the value v by quantifying the type variables $\beta_1, \dots, \beta_n$ . Namely, we further rewrite $M_1'$ to

Second, we use the following type containment for the parameter type A:

\[ \forall \beta_1 \dots \beta_n.\, A[C/\alpha] \sqsubseteq A[\forall \beta_1 \dots \beta_n.\,C/\alpha] ~,\]

which is derivable using the polarity conditions of the signature restriction and an additional type containment rule, known as the distributive law:

\[ \forall \alpha.\, A \rightarrow B \sqsubseteq A \rightarrow \forall \alpha.\, B \quad \text{(if $\alpha$ does not occur free in} \textit{A}\text{)} ~.\]

The signature restriction is relaxed enough to accept many useful effects. For example, the type signature of select conforms to the signature restriction— $\alpha$ only occurs at a strictly positive position in the parameter type $\alpha \,\texttt{list}$ . As a result, we can ensure the safety of the calls to select in polymorphic expressions. Nevertheless, the signature restriction is still sound in that it rejects unsafe operations. For example, get_id does not conform to the signature restriction because, in its type signature $\forall \alpha.$ unit $\hookrightarrow (\alpha \rightarrow \alpha)$ , the bound type variable $\alpha$ occurs negatively in the arity type $\alpha \rightarrow \alpha$ .

The signature restriction has the following advantages over the previous approaches. By contrast with the approaches that restrict the use of effects, it allows polymorphic expressions to invoke any effect meeting the required restriction. By contrast with the approach that restricts effect handlers, the signature restriction is easily adaptable to allow the use of any polymorphic effect in monomorphic contexts, as shown in Section 6. Furthermore, the signature restriction is easy to understand once one admits the notion of polarities of type variables.

3.1 Syntax

Figure 1 presents the syntax of $\lambda_{\text{eff}}$ . We use the metavariables x, y, z, f, k for variables and $\mathsf{op}$ for effect operations. Our language $\lambda_{\text{eff}}$ is parameterized over constants, which are ranged over by c and may include basic values, such as Boolean and integer values, and basic operations for them, such as $\mathsf{not}$ , $+$ , $-$ , $\mathsf{mod}$ , etc.

Fig 1.

Syntax of $\lambda_{\text{eff}}$ .

Terms, ranged over by M, are from the $\lambda$ -calculus, augmented with constructs for algebraic effects and handlers. They are composed of: variables; constants; lambda abstractions $ \lambda\! \, x {.} {M}$ , where variable x is bound in M; function applications ${M_{{\mathrm{1}}}} \, {M_{{\mathrm{2}}}}$ ; operation calls $ {\textrm{#}} \mathsf{op} (M) $ with arguments M; and $\mathsf{handle}$ – $\mathsf{with}$ expressions $\mathsf{handle} \, {M} \, \mathsf{with} \, {H}$ , which install a handler H to interpret effect operations performed during the evaluation of M. A resumption expression resume M that appears in Section 2 is the syntactic sugar of function application $k \, {M}$ where k is a variable that denotes delimited continuations and is introduced by an operation clause in a handler (we will see the definition of operation clauses shortly). The definition of evaluation contexts, ranged over by E, is standard; it indicates that the semantics of $\lambda_{\text{eff}}$ is call-by-value and terms are evaluated from left to right.

Handlers, ranged over by H, consist of a single return clause and zero or more operation clauses. A return clause takes the form $\mathsf{return} \, x \rightarrow {M}$ , where x is bound in M. The body M is evaluated once a handled expression produces a value, to which x is bound in M. An operation clause $\mathsf{op} {(} x {,} k {)} \rightarrow {M}$ , where x and k are bound in M, is an implementation of the effect operation $\mathsf{op}$ . The body M is evaluated once a handled expression performs $\mathsf{op}$ , referring to the argument of $\mathsf{op}$ by x. Variable k denotes the delimited continuation from the point where $\mathsf{op}$ is called up to the $\mathsf{handle}$ – $\mathsf{with}$ expression that installs the operation clause. We suppose that a handler may contain at most one operation clause for each operation.

Here, we introduce a few notions about syntax; they are standard, and therefore we omit their formal definitions. We write $ {M_{{\mathrm{1}}}} [ {M_{{\mathrm{2}}}} / x ] $ for the term obtained by substituting ${M_{{\mathrm{2}}}}$ for x in ${M_{{\mathrm{1}}}}$ in a capture-avoiding manner. A term M is closed if it has no free variable. We also write E [ M ] and E [ E’ ] for the term and evaluation context obtained by filling the hole of E with M and E’, respectively.

3.2 Semantics

This section defines the semantics of $\lambda_{\text{eff}}$ . It consists of two binary relations over closed terms: the reduction relation $ \rightsquigarrow $ , which gives the notion of basic computation such as $\beta$ -reduction, and the evaluation relation $ \longrightarrow $ , which defines how to evaluate programs (namely, closed terms). These relations are defined by the rules shown in Figure 2.

Fig 2.

Semantics of $\lambda_{\text{eff}}$ .

The reduction relation is defined by four rules. The rule is for constant applications. The semantics of functional constants are given by $ \zeta $ , which is a partial mapping from pairs of a constant c and a value v to the value that is the result of applying c to v. A function application ${(} \lambda\! \, x {.} {M} {)} \, {v}$ reduces to $ {M} [ {v} / x ] $ , as usual, by . The other two rules are for computation in terms of algebraic effects and handlers. The rule is for the case that a handled expression evaluates to a value. In such a case, the return clause of the installed handler is evaluated with the value of the handled expression. We write $ {H} ^\mathsf{return} $ for the return clause of a handler H. The rule is the core of effectful computation in algebraic effects and handlers. It looks for an operation clause to interpret an operation invoked by a handled expression. The redex is a $\mathsf{handle}$ – $\mathsf{with}$ expression that takes the form $\mathsf{handle} \, {E} [ {\textrm{#}} \mathsf{op} {(} {v} {)} ] \, \mathsf{with} \, {H}$ where the handled expression $E[{\#} \mathsf{op} (v)] $ performs the operation $\mathsf{op}$ and E does not install handlers to interpret it. We call evaluation contexts that install no handler to interpret $\mathsf{op}$ $\mathsf{op}$ -transparent, which is formally defined as follows.

We also denote the operation clause for $\mathsf{op}$ in H by ${H} {(} \mathsf{op} {)}$ . Then, the conjunction of $\mathsf{op} \, \not\in \, {E}$ and ${H} {(} \mathsf{op} {)} \, = \, \mathsf{op} {(} x {,} k {)} \rightarrow {M}$ in means that the operation clause $\mathsf{op} {(} x {,} k {)} \rightarrow {M}$ installed by the $\mathsf{handle}$ – $\mathsf{with}$ expression is the innermost among the operation clauses for $\mathsf{op}$ from the point at which $\mathsf{op}$ is invoked. The $\mathsf{handle}$ – $\mathsf{with}$ expression with such an operation clause reduces to the body M of the operation clause after substituting the argument v of the operation call for x and the functional representation of the delimited continuation $ \lambda\! \, y {.} \mathsf{handle} \, {E} [ y ] \, \mathsf{with} \, {H}$ for k.

The evaluation proceeds according to the evaluation rule in Figure 2. A program is decomposed into the evaluation context E and the redex ${M_{{\mathrm{1}}}}$ and evaluates to the term $ {E} [ {M_{{\mathrm{2}}}} ] $ obtained by filling the hole of E with the reduction result ${M_{{\mathrm{2}}}}$ of the redex ${M_{{\mathrm{1}}}}$ .

4.1 Type language

Figure 3 presents the type language of the polymorphic type system. It is the same as that of System F (Reynolds, Reference Reynolds1974; Girard, Reference Girard1972) with base types. We use metavariables $\alpha$ , $\beta$ , $\gamma$ for type variables and $\iota$ for base types such as $ \mathsf{bool} $ and $ \mathsf{int} $ . Types, ranged over by A, B, C, D, consist of: type variables; base types; function types $A \rightarrow B$ ; and polymorphic types $ \forall \, \alpha {.} \, A$ , where type variable $\alpha$ is bound in type A. Typing contexts, ranged over by $\Gamma$ , are sequences of bindings of variables coupled with their types and type variables. We suppose that the metafunction $ \mathit{ty} $ assigns to each constant c a first-order closed type $ \mathit{ty} ( {c} ) $ of the form $\iota \rightarrow \cdots \rightarrow \iota_{{n}}$ . We state the assumption on the consistency between the types and semantics of constants later (Assumption 1).

Fig 3.

The type language.

We use the following shorthand and notions. We write $ \boldsymbol{ \alpha }^{ {\mathit{I}} } $ for $ \boldsymbol{ \alpha } = \alpha_{{\mathrm{1}}}, \cdots, \alpha_{{n}}$ with the index set ${\mathit{I}} = \{ 1,..., n \}$ . We apply this bold-font notation to other syntax categories as well. For example, $ \boldsymbol{ A }^{ {\mathit{I}} } $ denotes a sequence of types. We often omit the index sets ( ${\mathit{I}}$ , ${\mathit{J}}$ , ${\mathit{K}}$ ) if they are clear from the context or irrelevant. For instance, we may abbreviate $ \boldsymbol{ \alpha }^{ {\mathit{I}} } $ to $ \boldsymbol{ \alpha } $ . We also write $ \forall \, \boldsymbol{ \alpha }^{ {\mathit{I}} } {.} \, A$ for $ \forall \alpha_{{\mathrm{1}}} . \, ... \, \forall \alpha_{{n}} . \, A$ with ${\mathit{I}} = \{ 1, ..., n\}$ . We may omit the index sets and write $ \forall \, \boldsymbol{ \alpha } {.} \, A$ simply. We write $ {\boldsymbol{ \forall} , \boldsymbol{ \alpha }^{{I}} {.} \, A }^{ \mathit{J}} $ for a sequence of types $ \forall \, \boldsymbol{ \alpha }^{ {\mathit{I}} } {.} \, A_1$ , …, $ \forall \, \boldsymbol{ \alpha }^{ {\mathit{I}} } {.} \, A_n$ with ${\mathit{J}} = \{1,\ldots,n\}$ . The notions of free type variables and capture-avoiding type substitution are defined as usual. We write $ \mathit{ftv} ( A ) $ for the set of free type variables of type A and $ A [ \boldsymbol{ B } {/} \boldsymbol{ \alpha } ] $ for the type obtained by substituting each type of the sequence $ \boldsymbol{ B }$ for the corresponding type variable of the sequence $\boldsymbol{ \alpha } $ simultaneously (here we suppose that $ \boldsymbol{ B } $ and $ \boldsymbol{ \alpha }$ share the same, omitted index set).

4.2 Polymorphic type system

We present a polymorphic type system for $\lambda_{\text{eff}}$ , which consists of four judgments: well-formedness judgment $\vdash \Gamma$ , which states that a typing context $\Gamma$ is well formed; type containment judgment $\Gamma \vdash A \sqsubseteq B$ , which states that, for the types A and B, which are assumed to be well formed under $\Gamma$ , the inhabitants of A are contained in B; term typing judgment $\Gamma \vdash {M} {:} A$ , which states that term M evaluates to a value of type A after applying an appropriate substitution for variables and type variables in $\Gamma$ ; and handler typing judgment $\Gamma \vdash {H} {:} A \Rightarrow B$ , which states that handler H handles operations called by a handled term of type A and produces a value of type B after applying appropriate substitution according to $\Gamma$ (we refer to A and B as the input and output types of the handler, respectively). These judgments are defined as the smallest relations that satisfy the rules in Figure 4.

Fig 4.

Polymorphic type system for $\lambda_{\text{eff}}$ .

The well-formedness rules are standard. A typing context is well formed if (1) variables and type variables bound by it are unique and (2) it assigns well-formed types to the variables. We write $ \mathit{dom} ( \Gamma ) $ for the set of variables and type variables bound by $\Gamma$ . A type A is well formed under typing context $\Gamma$ , which is expressed by $\Gamma \vdash A$ , if and only if $ \mathit{ftv} ( A ) \, \subseteq \, \mathit{dom} ( \Gamma ) $ (i.e., $\Gamma$ binds all of the free type variables in A).

The type containment rules originate from the work of Tiuryn and Urzyczyn (Reference Tiuryn and Urzyczyn1996), which simplifies the rules of type containment of Mitchell (Reference Mitchell1988). The rules and indicate that type containment is a preorder. The rule instantiates polymorphic types with well-formed types. The rule may add a universal quantifier $\forall$ if the quantifier does not bind free type variables. The rules and are for compatibility; note that type containment is a kind of subtyping and hence it is contravariant on the domain types of function types. The rule is a simplified version (Tiuryn and Urzyczyn, Reference Tiuryn and Urzyczyn1996) of the original “distributive” law (Mitchell, Reference Mitchell1988), which is the core of type containment. This rule allows $\forall$ that quantifies a function type to move to its codomain type if the quantified type variable does not occur free in the domain type. This rule is justified by the fact that we can supply a function from $ \forall \, \alpha {.} \, A \rightarrow B$ to $A \rightarrow \forall \, \alpha {.} \, B$ in System F and the result of applying type erasure to it is equivalent to the identity function (Mitchell, Reference Mitchell1988). This rule is crucial for allowing the parameter type of a type signature to refer to quantified type variables in strictly positive positions, which makes signature restriction permissive.

The typing rules for terms are almost standard, coming from Mitchell (Reference Mitchell1988) for polymorphism and Plotkin and Pretnar (Reference Plotkin and Pretnar2013) for effects. The rule converts types by type containment. The rule is for operation calls. We formalize a type signature of an operation as follows.

We note that parameter and arity types may involve polymorphic types.

The rule instantiates the type signature of the operation with well-formed types and checks that an argument is typed at the parameter type of the instantiated type signature. We use notation $\Gamma \vdash \boldsymbol{ C } $ for the conjunction of $\Gamma \vdash C_{{\mathrm{1}}}, {\cdots}, \Gamma \vdash C_{{n}}$ when $ \boldsymbol{ C } = C_{{\mathrm{1}}}, {\cdots}, C_{{n}}$ .

The typing rules for handlers are also ordinary (Plotkin and Pretnar, Reference Plotkin and Pretnar2013). A return clause $\mathsf{return} \, x \rightarrow {M}$ is typechecked by , which allows the body M to refer to the values of the handled expression via bound variable x. An operation clause $\mathsf{op} {(} x {,} k {)} \rightarrow {M}$ is typechecked by . Let the type signature of $\mathsf{op}$ be $ \forall \, \boldsymbol{ \alpha } {.} \, C \hookrightarrow D $ . In typechecking M, variable x is assumed to have the parameter type C since variable x will be bound to the arguments to the operation $\mathsf{op}$ . Variable k is given type $D \rightarrow B$ where the type B is the output type of the handler. This is because k will be bound to the functional representations of delimited continuations such that: the delimited continuations suppose that their holes are filled with values of the arity type D of the type signature; and they are wrapped by the $ \mathsf{handle} $ – $ \mathsf{with} $ expression installing the handler and therefore they would produce values of the type B.

4.3 Desired properties for type soundness

As mentioned in Section 2.3, the polymorphic type system is unsound—a well-typed program can get stuck—if we impose no further restriction on it. This section details the proof sketch of type preservation provided in Section 2.4 and formulates two propositions such that they do not hold in the polymorphic type system but, if they did, the type system would be sound. In Section 4.4.2, we show that the propositions hold if all operations satisfy signature restriction.

We start by considering an issue that arises when proving soundness of the polymorphic type system. This issue relates to the handling of an operation call by , which enables the following reduction:

(4.1)

where $\mathsf{op} \, \not\in \, {E}$ and ${H} {(} \mathsf{op} {)} \, = \, \mathsf{op} {(} x {,} k {)} \rightarrow {M}$ . The problem is that the RHS term does not preserve the type of the LHS term. If this type preservation were successful, we would be able to prove soundness of the polymorphic type system, but it is contradictory to the existence of the counterexample presented in Section 2.3.

A detailed investigation of this problem reveals two propositions that are lacking but sufficient to make the polymorphic type system sound.

In what follows, we show how these two propositions allow us to prove type soundness. Before that, we first fix and examine the type information of the terms appearing in the LHS term of reduction (4.1). Assume that $\mathit{ty} \, {(} \mathsf{op} {)} \, = \, \forall \, \boldsymbol{ \alpha }^{ {\mathit{I}} } {.} \, A \hookrightarrow B $ and that the LHS term has a type D under a typing context $\Gamma$ . We can then find that

(4.2) \begin{equation} \Gamma {,} \boldsymbol{ \alpha }^{ {\mathit{I}} } {,} x \, \mathord{:} \, A {,} k \, \mathord{:} \, B \rightarrow D \vdash {M} {:} D \end{equation}

must have held by the use of the typing rule . Turning to the handled expression , we can find two facts about the typing judgment for the value v. The first fact originates from : since the value v is an argument of operation $\mathsf{op}$ , it should be of type $ A [ \boldsymbol{ C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ] $ , which is a type obtained by substituting certain types $ \boldsymbol{ C }^{ {\mathit{I}} } $ for type variables $ \boldsymbol{ \alpha }^{ {\mathit{I}} } $ in the parameter type A of the operation $\mathsf{op}$ . The second is from , which allows the generalization of types anywhere. Thus, the value v is well typed under a typing context $\Gamma {,} \boldsymbol{ \beta }^{ {\mathit{J}} } $ , an extension of $\Gamma$ with some type variables $ \boldsymbol{ \beta }^{ {\mathit{J}} } $ (note that ${\mathit{I}} \neq {\mathit{J}}$ in general). In summary, the typing judgment for the value v takes the following form:

(4.3) \begin{equation} \Gamma {,} \boldsymbol{ \beta }^{ {\mathit{J}} } \vdash {v} {:} A [ \boldsymbol{ C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ] ~. \end{equation}

Now, we show that Proposition 1 makes $ {M} [ {v} / x ] $ typed at the type D. First, we can derive

\[ \Gamma \vdash {v} {:} \forall \, \boldsymbol{ \beta }^{ {\mathit{J}} } {.} \, A [ \boldsymbol{ C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ]\]

by the typing derivation of judgment (4.3) and . Proposition 1 enables us to prove

(4.4) \begin{equation} \Gamma \vdash {v} {:} A [ {\boldsymbol{ \forall} \, \boldsymbol{ \beta }^{ {\mathit{J}} } {.} \, C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ] ~. \end{equation}

We can also derive

\[ \Gamma {,} x \, \mathord{:} \, A \, [ { \boldsymbol{ \forall} \, \boldsymbol{ \beta }^{ {\mathit{J}} } {.} \, C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ] {,} k \, \mathord{:} \, B [ { \boldsymbol{ \forall } \, \boldsymbol{ \beta }^{ {\mathit{J}} } {.} \, C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ] \rightarrow D \vdash {M} {:} D\]

by substituting $ {\boldsymbol{ \forall} \, \boldsymbol{ \beta }^{ {\mathit{J}} } {.} \, C }^{ {\mathit{I}} } $ for $ \boldsymbol{ \alpha }^{ {\mathit{I}} } $ in the typing judgment (4.2); note that the type variables in $ \boldsymbol{ \alpha }^{ {\mathit{I}} } $ do not occur free in D because they are bound by the type signature. Thus, we can derive

(4.5) \begin{equation} \Gamma {,} k \, \mathord{:} \, B [ {\boldsymbol{ \forall} \, \boldsymbol{ \beta }^{ {\mathit{J}} } {.} \, C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ] \rightarrow D \vdash {M} [ {v} / x ] {:} D \end{equation}

using an ordinary substitution lemma with the derivation for judgment (4.4).

Next, we show that Proposition 2 makes $ {M} [ {v} / x ] [ \lambda\! \, y {.} \mathsf{handle} \, {E} [ y ] \, \mathsf{with} \, {H} / k ] $ typed at the type D. This is possible if

\[ \Gamma \vdash \lambda\! \, y {.} \mathsf{handle} \, {E} [ y ] \, \mathsf{with} \, {H} {:} B [ { \boldsymbol{ \forall } \, \boldsymbol{ \beta }^{ {\mathit{J}} } {.} \, C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ] \rightarrow D\]

is derivable, jointly with the derivation of typing judgment (4.5). Namely, it suffices to derive

\[ \Gamma {,} y \, \mathord{:} \, B \, [ {\boldsymbol{ \forall } \, \boldsymbol{ \beta }^{ {\mathit{J}} } {.} \, C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ] \vdash \mathsf{handle} \, {E} [ y ] \, \mathsf{with} \, {H} {:} D ~.\]

By an observation similar to the value v, we find that is typed at the type $ B [ \boldsymbol{ C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ] $ under $\Gamma {,} \boldsymbol{ \beta }^{ {\mathit{J}} } $ (note that B is the arity type of $\mathsf{op}$ ). Thus, for the above typing judgment to hold, it suffices for the variable y to have the same type as . Hence, we will derive

(4.6) \begin{equation} \Gamma {,} y \, \mathord{:} \, B \, [ {\boldsymbol{ \forall} \, \boldsymbol{ \beta }^{ {\mathit{J}} } {.} \, C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ] {,} \boldsymbol{ \beta }^{ {\mathit{J}} } \vdash y {:} B [ \boldsymbol{ C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ] ~. \end{equation}

Because $\Gamma {,} y \, \mathord{:} \, B \, [ { \boldsymbol{ \forall} \, \boldsymbol{ \beta }^{ {\mathit{J}} } {.} \, C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ] {,} \boldsymbol{ \beta }^{ {\mathit{J}} } \vdash y {:} B [ { \boldsymbol{ \forall } \, \boldsymbol{ \beta }^{ {\mathit{J}} } {.} \, C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ] $ , we can derive

\[ \Gamma {,} y \, \mathord{:} \, B \, [ { \boldsymbol{ \forall } \, \boldsymbol{ \beta }^{ {\mathit{J}} } {.} \, C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ] {,} \boldsymbol{ \beta }^{ {\mathit{J}} } \vdash y {:} \forall \, \boldsymbol{ \beta }^{ {\mathit{J}} } {.} \, B [ \boldsymbol{ C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ]\]

by Proposition 2. Furthermore, by instantiating $ \forall \, \boldsymbol{ \beta }^{ {\mathit{J}} } {.} \, B [ \boldsymbol{ C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ] $ to $ B [ \boldsymbol{ C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ] $ with $ \boldsymbol{ \beta }^{ {\mathit{J}} } $ in the typing context, we have succeeded in deriving the typing judgment (4.6).

Thus, if Propositions 1 and 2 held, we could derive

\[ \Gamma \vdash {M} [ {v} / x ] [ \lambda\! \, y {.} \mathsf{handle} \, {E} [ y ] \, \mathsf{with} \, {H} / k ] {:} D ~.\]

The polymorphic type system in Section 4.2 does not actually

support these properties, but imposing signature restriction produces a type system that does.

4.4 Signature restriction

This section formalizes signature restriction for $\lambda_{\text{eff}}$ and shows that it implies Propositions 1 and 2.

4.4.1 Definition

As described in Section 2.4, signature restriction rests on the polarity of the occurrences of quantified type variables in a type signature. The polarity is defined in a standard manner, as follows.

Definition 3 (Polarity of type variable occurrence). The sets $ \mathit{ftv} ( A )^+ $ and $ \mathit{ftv} ( A )^- $ of type variables that occur positively and negatively, respectively, in type A are defined by induction on A, as follows.

\[\begin{array}{lll} \mathit{ftv} ( \alpha )^+ &\stackrel{\rm \tiny def}{=}& {\{} \alpha {\}} \\ \mathit{ftv} ( \alpha )^- &\stackrel{\rm \tiny def}{=}& \emptyset \\ \mathit{ftv} ( A \rightarrow B )^{\pm} &\stackrel{\rm \tiny def}{=}& \mathit{ftv} ( A )^{\mp} \, \mathbin{\cup} \, \mathit{ftv} ( B )^{\pm} \\ \mathit{ftv} ( \forall \, \alpha {.} \, A )^{\pm} &\stackrel{\rm \tiny def}{=}& \mathit{ftv} ( A )^{\pm} \, \mathbin{\backslash} \, {\{} \alpha {\}} \end{array} \]

The set $ \mathit{ftv} ( A )^+_\mathbf{ns} $ of type variables that occur non-strictly positively in type A is defined as follows.

\[\begin{array}{lll} \mathit{ftv} ( \alpha )^+_\mathbf{ns} &\stackrel{\rm \tiny def}{=}& \emptyset \\ \mathit{ftv} ( A \rightarrow B )^+_\mathbf{ns} &\stackrel{\rm \tiny def}{=}& \mathit{ftv} ( A )^- \, \mathbin{\cup} \, \mathit{ftv} ( B )^+_\mathbf{ns} \\ \mathit{ftv} ( \forall \, \alpha {.} \, A )^+_\mathbf{ns} &\stackrel{\rm \tiny def}{=}& \mathit{ftv} ( A )^+_\mathbf{ns} \, \mathbin{\backslash} \, {\{} \alpha {\}} \end{array} \]

Now, we define signature restriction. We write ${\{} \boldsymbol{ \alpha }^{ {\mathit{I}} } {\}}$ to view the sequence $ \boldsymbol{ \alpha }^{ {\mathit{I}} } $ as a set by ignoring the order.

Definition 4 (Signature restriction). defndefnSignatureRestriction An operation $\mathsf{op}$ with type signature $\mathit{ty} \, {(} \mathsf{op} {)} \, = \, \forall \, \boldsymbol{ \alpha } {.} \, A \hookrightarrow B $ satisfies the signature restriction if and only if: (1) the occurrences of each type variable of $ \boldsymbol{ \alpha } $ in the parameter type A are only negative or strictly positive (i.e., ${\{} \boldsymbol{ \alpha } {\}} \, \mathbin{\cap} \, \mathit{ftv} ( A )^+_\mathbf{ns} \, = \, \emptyset $ ) and (2) the occurrences of each type variable of $ \boldsymbol{ \alpha } $ in the arity type B are only positive (i.e., ${\{} \boldsymbol{ \alpha } {\}} \, \mathbin{\cap} \, \mathit{ftv} ( B )^- \, = \, \emptyset $ ).

The signature restriction allows quantified type variables to occur at strictly positive positions of the parameter type of a type signature. This is crucial for some operations, such as select, to conform to signature restriction. The rule plays an important role to permit this capability, as seen in the next section.

We can easily confirm whether an operation satisfies the signature restriction. For example, it is easy to determine that get_id does not satisfy the signature restriction: since its type signature is $ \forall \, \alpha {.} \, \mathsf{unit} \hookrightarrow \alpha \rightarrow \alpha $ , the quantified type variable $\alpha$ occurs not only at a positive position but also at a negative position in the arity type $\alpha \rightarrow \alpha$ . By contrast, the operations raise and fail given in Section 2 satisfy the signature restriction because their type signature $ \forall \, \alpha {.} \, \mathsf{unit} \hookrightarrow \alpha $ meets the conditions in Definition 4. To determine whether select satisfies the signature restriction, we need to extend $\lambda_{\text{eff}}$ and the polymorphic type system by introducing other programming constructs such as lists. Particulars of this extension are presented in Section 5, but, briefly speaking, the type signature $ \forall \, \alpha {.} \, \alpha \, \mathsf{list} \hookrightarrow \alpha $ of select satisfies the signature restriction because the type variable $\alpha$ occurs only strictly positively in the parameter type $ \alpha \, \mathsf{list} $ and only positively in the arity type $\alpha$ .

4.4.2 Proofs of the desired properties

The signature restriction enables us to prove Propositions 1 and 2, which are crucial to show that reduction preserves typing. Below is the key lemma for that.

Lemma 1. lemmlemmSubtypingForallMove Assume that $\vdash \Gamma$ and $\alpha \, \not\in \, \mathit{ftv} ( A ) $ .

1. 1. If $\beta \, \not\in \, \mathit{ftv} ( A )^+_\mathbf{ns} $ , then $\Gamma \vdash \forall \, \alpha {.} \, A [ B {/} \beta ] \sqsubseteq A [ \forall \, \alpha {.} \, B {/} \beta ] $ .

2. 2. If $\beta \, \not\in \, \mathit{ftv} ( A )^- $ , then $\Gamma \vdash A [ \forall \, \alpha {.} \, B {/} \beta ] \sqsubseteq \forall \, \alpha {.} \, A [ B {/} \beta ] $ .

This lemma means that an operation $\mathsf{op}$ conforming to the signature restriction satisfies Propositions 1 and 2. For Proposition 1: assume $\mathit{ty} \, {(} \mathsf{op} {)} \, = \, \forall \, \boldsymbol{ \alpha }^{ {\mathit{I}} } {.} \, A \hookrightarrow B $ and $\Gamma \vdash {M} {:} \forall \, \boldsymbol{ \beta }^{ {\mathit{J}} } {.} \, A [ \boldsymbol{ C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ] $ ; since $\mathsf{op}$ satisfies the signature restriction, we can apply case (1) of Lemma 1, which implies $\Gamma \vdash \forall \, \boldsymbol{ \beta }^{ {\mathit{J}} } {.} \, A [ \boldsymbol{ C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ] \sqsubseteq A [ {\boldsymbol{ \forall} \, \boldsymbol{ \beta }^{ {\mathit{J}} } {.} \, C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ] $ ; thus, we can derive $\Gamma \vdash {M} {:} A [ { \boldsymbol{ \forall } \, \boldsymbol{ \beta }^{ {\mathit{J}} } {.} \, C }^{ {\mathit{I}} } {/} \boldsymbol{ \alpha }^{ {\mathit{I}} } ] $ by . Proposition 2 is proven similarly by using case (1) of Lemma 1 instead of case (1).

We start by proving that any type A can be regarded as a type constructor contravariant and covariant with respect to a type variable $\alpha$ if $\alpha$ occurs only negatively and positively, respectively, in A.

Lemma 2. lemmlemmSubtypingFunctoriality Assume that $\Gamma \vdash B \sqsubseteq C$ .

1. 1. If $\alpha \, \not\in \, \mathit{ftv} ( A )^+ $ , then $\Gamma \vdash A [ C {/} \alpha ] \sqsubseteq A [ B {/} \alpha ] $ .

2. 2. If $\alpha \, \not\in \, \mathit{ftv} ( A )^- $ , then $\Gamma \vdash A [ B {/} \alpha ] \sqsubseteq A [ C {/} \alpha ] $ .

Proof. Straightforward by induction on A.

Now, we prove Lemma 1 (1) using Lemma 2, and then Lemma 1 (1) using Lemma 1 (1) and , which is the key rule for the signature restriction to allow strictly positive occurrences of quantified type variables in the parameter type of a type signature.

Proof of Lemma 1 (2). By , it suffices to show that $\Gamma \vdash A [ \forall \, \alpha {.} \, B {/} \beta ] \sqsubseteq \forall \, \alpha {.} \, A [ \forall \, \alpha {.} \, B {/} \beta ] $ and $\Gamma \vdash \forall \, \alpha {.} \, A [ \forall \, \alpha {.} \, B {/} \beta ] \sqsubseteq \forall \, \alpha {.} \, A [ B {/} \beta ] $ . The former is derived by . The latter is derived as follows, where we have $\vdash \Gamma {,} \alpha $ because we can assume that $\alpha \, \not\in \, \mathit{dom} ( \Gamma ) $ without loss of generality:

Proof of Lemma 1 (1). By induction on type A. Here, we consider only the interesting cases: A is a function type or a polymorphic type; see the supplementary material for the other cases.

Case $A \, = \, C \rightarrow D$ for some C and D: By the assumption $\beta \, \not\in \, \mathit{ftv} ( A )^+_\mathbf{ns} = \mathit{ftv} ( C \rightarrow D )^+_\mathbf{ns} $ , we have $\beta \, \not\in \, \mathit{ftv} ( C )^- $ and $\beta \, \not\in \, \mathit{ftv} ( D )^+_\mathbf{ns} $ . By , it suffices to show the following two type containment judgments:

\[\begin{array}{c} \Gamma \vdash \forall \, \alpha {.} \, C [ B {/} \beta ] \rightarrow D [ B {/} \beta ] \sqsubseteq {(} \forall \, \alpha {.} \, C [ B {/} \beta ] {)} \rightarrow \forall \, \alpha {.} \, D [ B {/} \beta ] \\ \Gamma \vdash {(} \forall \, \alpha {.} \, C [ B {/} \beta ] {)} \rightarrow \forall \, \alpha {.} \, D [ B {/} \beta ] \sqsubseteq C [ \forall \, \alpha {.} \, B {/} \beta ] \rightarrow D [ \forall \, \alpha {.} \, B {/} \beta ] ~. \end{array} \]

The former is derived using with the following two derivations:

and

The latter is derived as follows:

Note that $\alpha \, \not\in \, \mathit{ftv} ( C ) \, \mathbin{\cup} \, \mathit{ftv} ( D ) = \mathit{ftv} ( A ) $ .

Case $A \, = \, \forall \, \gamma {.} \, C$ for some $\gamma$ and C: Without loss of generality, we can assume that $\gamma \, \not\in \, {\{} \alpha {,} \beta {\}} \, \mathbin{\cup} \, \mathit{dom} ( \Gamma ) \, \mathbin{\cup} \, \mathit{ftv} ( B ) $ . Because $\beta \, \not\in \, \mathit{ftv} ( A )^+_\mathbf{ns} $ , we have $\beta \, \not\in \, \mathit{ftv} ( C )^+_\mathbf{ns} $ . Furthermore, $\vdash \Gamma {,} \gamma $ as $\vdash \Gamma$ , and $\alpha \, \not\in \, \mathit{ftv} ( C ) $ as $\alpha \, \not\in \, \mathit{ftv} ( A ) $ . Thus, by the IH, $\Gamma {,} \gamma \vdash \forall \, \alpha {.} \, C [ B {/} \beta ] \sqsubseteq C [ \forall \, \alpha {.} \, B {/} \beta ] $ . By , $\Gamma \vdash \forall \, \gamma {.} \forall \, \alpha {.} \, C [ B {/} \beta ] \sqsubseteq \forall \, \gamma {.} \, C [ \forall \, \alpha {.} \, B {/} \beta ] $ . Because the type containment allows the commutation of universal quantifiers (see Lemma 9 in the supplementary material for detail), we have $\Gamma \vdash \forall \, \alpha {.} \forall \, \gamma {.} \, C [ B {/} \beta ] \sqsubseteq \forall \, \gamma {.} \forall \, \alpha {.} \, C [ B {/} \beta ] $ . Thus, by , $\Gamma \vdash \forall \, \alpha {.} \forall \, \gamma {.} \, C [ B {/} \beta ] \sqsubseteq \forall \, \gamma {.} \, C [ \forall \, \alpha {.} \, B {/} \beta ] $ , that is, $\Gamma \vdash \forall \, \alpha {.} \, A [ B {/} \beta ] \sqsubseteq A [ \forall \, \alpha {.} \, B {/} \beta ] $ .

4.5 Type soundness

This section shows soundness of the polymorphic type system under the assumption that all operations satisfy the signature restriction. As usual, our proof rests on two properties: progress and subject reduction (Wright and Felleisen, Reference Wright and Felleisen1994). As discussed in Sections 4.3 and 4.4, the signature restriction, together with type containment, enables us to prove subject reduction.

Type containment is thus a key notion to prove type soundness, but proving its inversion properties is complicated. In the literature (Peyton Jones et al., Reference Peyton Jones, Vytiniotis, Weirich and Shields2007; Dunfield and Krishnaswami, Reference Dunfield and Krishnaswami2013), type soundness of a language with subtyping based on type containment has been shown by translation to another language—typically, System F—where the use of subtyping is replaced by “coercions” (i.e., certain term representations for type conversion by subtyping). This approach is acceptable in the prior work because the semantics of the source language is determined by the target language. However, this approach is not acceptable in our setting because the terms checked by our type system should be interpreted by the semantics of $\lambda_{\text{eff}}$ as they are. We thus show soundness of the polymorphic type system directly, without translation to other languages.

The most difficult property to prove is the inversion of type containment judgments relating function types.

We cannot prove this lemma as it is by induction on the derivation of $\Gamma \vdash A_{{\mathrm{1}}} \rightarrow A_{{\mathrm{2}}} \sqsubseteq B_{{\mathrm{1}}} \rightarrow B_{{\mathrm{2}}}$ because a premise in the derivation may relate the (monomorphic) function type on one side to a polymorphic function type on the other side. Thus, we need to generalize the assumption to a type containment judgment that may relate polymorphic function types: $\Gamma \vdash \forall \, \boldsymbol{ \alpha }^{ {\mathit{I}} } {.} \, A_{{\mathrm{1}}} \rightarrow A_{{\mathrm{2}}} \sqsubseteq \forall \, \boldsymbol{ \beta }^{ {\mathit{J}} } {.} \, B_{{\mathrm{1}}} \rightarrow B_{{\mathrm{2}}}$ . By investigating the type containment rules, we find that $ \boldsymbol{ \alpha }^{ {\mathit{I}} } $ is split into three sequences $ \boldsymbol{ \alpha_{{\mathrm{01}}} }^{ \text{I}_01}$ , $ \boldsymbol{\alpha}_{\mathrm{02}}^{\text{I}_{02}}$ , and $\boldsymbol{\alpha}_{03}^{ \text{I}_{03}}$ depending on how the rules handle the type variables in $ \boldsymbol{ \alpha }^{ {\mathit{I}} } $ : those of $ \boldsymbol{\alpha}_{01}^{\text{I}_01}$ stay in $ \boldsymbol{ \beta }^{ {\mathit{J}} } $ ; those of $ \boldsymbol{ \alpha}_{02}^{ \text{I}_02}$ are quantified in the return type $B_{{\mathrm{2}}}$ ; and those of $ \boldsymbol{\alpha}_{03}^{ \text{I}_{03}}$ are instantiated with some types $ \boldsymbol{ C}_{0}^{ \text{I}_{03}}$ . Furthermore, we have to take into account certain, unrevealed type variables $ \boldsymbol{ \gamma }^{ {\mathit{K}} } $ that initially emerge at the outermost position by and are subsequently distributed into subcomponent types. For example:

\[ A_{{\mathrm{1}}} \rightarrow A_{{\mathrm{2}}} \sqsubseteq \forall \, \gamma {.} \, A_{{\mathrm{1}}} \rightarrow A_{{\mathrm{2}}} \sqsubseteq {(} \forall \, \gamma {.} \, A_{{\mathrm{1}}} {)} \rightarrow {(} \forall \, \gamma {.} \, A_{{\mathrm{2}}} {)}\]

where $\gamma \, \not\in \, \mathit{ftv} ( A_{{\mathrm{1}}} ) \, \mathbin{\cup} \, \mathit{ftv} ( A_{{\mathrm{2}}} ) $ .

These observations are formulated in the following inversion lemma for type containment, which implies Lemma 3. We write ${\{} \boldsymbol{ \alpha }^{ {\mathit{I}} } {\}} \, \mathbin{\uplus} \, {\{} \boldsymbol{ \beta }^{ {\mathit{J}} } {\}}$ for the union of disjoint sets ${\{} \boldsymbol{ \alpha }^{ {\mathit{I}} } {\}}$ and ${\{} \boldsymbol{ \beta }^{ {\mathit{J}} } {\}}$ .

• • ${\{} \boldsymbol{ \alpha }^{ {\mathit{I}} } {\}} \, = \, {\{} \boldsymbol{ \alpha_{{\mathrm{1}}} }^{ {\mathit{I}_{\mathrm{1}}} } {\}} \, \mathbin{\uplus} \, {\{} \boldsymbol{ \alpha_{{\mathrm{2}}}}^{ \mathit{I}_{2}} {\}}$ <,

• • $\Gamma {,} \boldsymbol{ \beta }^{ {\mathit{J}} } {,} \boldsymbol{ \gamma }^{ {\mathit{K}} } \vdash \boldsymbol{ C }^{ {\mathit{I}_{\mathrm{1}}} } $ ,

• • $\Gamma {,} \boldsymbol{ \beta }^{ {\mathit{J}} } \vdash B_{{\mathrm{1}}} \sqsubseteq \forall \, \boldsymbol{ \gamma }^{ {\mathit{K}} } {.} \, A_{{\mathrm{1}}} [ \boldsymbol{ C }^{ {\mathit{I}_{\mathrm{1}}} } {/} \boldsymbol{ \alpha_{{\mathrm{1}}} }^{ {\mathit{I}_{\mathrm{1}}} } ] $ ,

• • $\Gamma {,} \boldsymbol{ \beta }^{ {\mathit{J}} } \vdash \forall \, \boldsymbol{\alpha}_{2}^{ \mathit{I}_{2}} {.}$ $ \forall \, \boldsymbol{ \gamma }^{ {\mathit{K}} } {.} \, A_{{\mathrm{2}}} [ \boldsymbol{ C }^{ {\mathit{I}_{\mathrm{1}}} } {/} \boldsymbol{ \alpha_{{\mathrm{1}}} }^{ {\mathit{I}_{\mathrm{1}}} } ] \sqsubseteq B_{{\mathrm{2}}}$ , and

• • ${\{} \boldsymbol{ \gamma }^{ {\mathit{K}} } {\}} \, \mathbin{\cap} \, {(} \mathit{ftv} ( A_{{\mathrm{1}}} ) \, \mathbin{\cup} \, \mathit{ftv} ( A_{{\mathrm{2}}} ) {)} \, = \, \emptyset $ .

In the statement, the sequence $ \boldsymbol{ \alpha}_{2}^{ \mathit{I}_2}$ corresponds to $ \boldsymbol{ \alpha}_{02}^{ \mathit{I}_{02}}$ in the above informal description and $ \boldsymbol{ \alpha_{{\mathrm{1}}} }^{ {\mathit{I}_{\mathrm{1}}} } $ includes the type variables that remain in $\boldsymbol{ \beta }^{ {\mathit{J}} } $ (i.e., $ \boldsymbol{ \alpha}_{01}^{ \mathit{I}_{01} }$ ) and those instantiated with some types in $ \boldsymbol{ C }^{ {\mathit{I}_{\mathrm{1}}} } $ (i.e., $ \boldsymbol{ \alpha_{{\mathrm{03}}} }^{ \mathit{I}_{03}}$ ). Type substitution $ [ \boldsymbol{ C }^{ {\mathit{I}_{\mathrm{1}}} } {/} \boldsymbol{ \alpha_{{\mathrm{1}}} }^{ {\mathit{I}_{\mathrm{1}}} } ] $ replaces a type variable in $ \boldsymbol{ \alpha_{{\mathrm{01}}} }^{{I}_{01} }$ with itself. We omit the detailed proof of Lemma 4 from the article because of its complexity; interested readers are referred to the supplementary material.

Now, we show progress, subject reduction, and type soundness. In what follows, the metavariable $\Delta$ ranges over typing contexts that consist only of type variable bindings. Note that the polymorphic type system is not equipped with a mechanism to track effects, so the operations that are carried out may not be handled. For proving progress and subject reduction, we assume the consistency between the type and semantics of every functional constant as follows.

• • ${M} \longrightarrow {M'}$ for some M’;

• • M is a value; or

• • for some E, $\mathsf{op}$ , and v such that $\mathsf{op} \, \not\in \, {E}$ .

1. 1. If $\Delta \vdash {M_{{\mathrm{1}}}} {:} A$ and ${M_{{\mathrm{1}}}} \rightsquigarrow {M_{{\mathrm{2}}}}$ , then $\Delta \vdash {M_{{\mathrm{2}}}} {:} A$ .

2. 2. If $\Delta \vdash {M_{{\mathrm{1}}}} {:} A$ and ${M_{{\mathrm{1}}}} \longrightarrow {M_{{\mathrm{2}}}}$ , then $\Delta \vdash {M_{{\mathrm{2}}}} {:} A$ .

We write $ \longrightarrow^{*} $ for the reflexive, transitive closure of $ \longrightarrow $ and to mean that there exists no term M’ such that ${M} \longrightarrow {M'}$ .

• • M’ is a value; or

• • for some E, $\mathsf{op}$ , and v such that $\mathsf{op} \, \not\in \, {E}$ .

4.6 Is it possible to relax the signature restriction further?

It is natural to ask whether the signature restriction can be further relaxed. This section examines the condition of strictly positive occurrences of quantified type variables on parameter types (Section 4.6.1) and other criteria for the cases that, given a type signature, its bound type variables occur only in the parameter type (Section 4.6.2) or in the arity type (Section 4.6.3).

4.6.1 The condition of strictly positive occurrences is necessary

Consider a type signature $ \forall \, \alpha {.} \, A \hookrightarrow B $ . We show that a nonstrictly positive occurrence of $\alpha$ in the parameter type A is problematic. Let us consider a calculus with $ \mathsf{int} $ , $ \mathsf{bool} $ , and sum types $ D_{{\mathrm{1}}} + D_{{\mathrm{2}}} $ for simplicity (we write $\mathsf{inl} \, {M}$ and $\mathsf{inr} \, {M}$ for injection into sum types). Consider an operation op of the signature $ \forall \, \alpha {.} \, {(} {(} \alpha \rightarrow \mathsf{int} {)} \rightarrow \alpha {)} \hookrightarrow \alpha $ and let

where E is an evaluation context such that $x \, \mathord{:} \, \mathsf{bool} + \mathsf{int} \vdash {E} [ x ] {:} \mathsf{int} $ and $ {E} [ \mathsf{inr} \, \mathsf{true} ] $ causes a run-time error (it is easy to construct such E). It is not difficult to check that M has type $ \mathsf{int} $ . In , the type variable $\alpha$ bound by the type signature is instantiated with $\beta \rightarrow {(} \beta + \mathsf{int} {)}$ , and thus g has type $ \forall \, \beta {.} \, \beta \rightarrow {(} \beta + \mathsf{int} {)}$ . The type variable $\beta$ is instantiated with $ \mathsf{int} $ in $g \, 0 $ and with $ \mathsf{bool} $ in $g \, \mathsf{true} $ . Then the counterexample is given by

\begin{equation*} \mathsf{handle} \, {M} \, \mathsf{with} \, \mathsf{return} \, x \rightarrow x {;} \mathsf{op} {(} x {,} k {)} \rightarrow k \, {(} x \, k {)} ~:~ \mathsf{int} , \end{equation*}

which is reduced to $\mathsf{handle} \, {E} [ \mathsf{inr} \, \mathsf{true} ] \, \mathsf{with} \, \mathsf{return} \, x \rightarrow x {;} \mathsf{op} {(} x {,} k {)} \rightarrow k \, {(} x \, k {)}$ and causes an error.

4.6.3 Further relaxation for closed parameter types is harder

One may expect that the safety of an operation op : $\forall \alpha.\, A \hookrightarrow B$ where the type variable $\alpha$ does not appear in the parameter type A is reducible to the safety of op’ : $A \hookrightarrow (\forall \alpha. B)$ . Unfortunately, this is not true. A counterexample is get_id : $\forall \alpha.\, \mathtt{unit} \hookrightarrow (\alpha \to \alpha)$ and get_id’ : $\mathtt{unit} \hookrightarrow (\forall \alpha. \alpha \to \alpha)$ , of which the former is unsafe as we have seen but the latter is safe by the signature restriction. Actually, the translation replacing op with op’ does not preserve the typability of the handler. A handler of op can be seen as a term of type

\begin{equation*} \forall \alpha.\; A \to ((B \to C) \to C), \end{equation*}

where the type C is the output type of the handler, the type $B \to C$ is of continuations, and the type variable $\alpha$ never occurs in the output type C. This type is isomorphic to

\begin{equation*} A \to \forall \alpha. ((B \to C) \to C) \end{equation*}

and

\begin{equation*} A \to (\exists \alpha. (B \to C)) \to C \end{equation*}

but differs from the type for a handler for op’

\begin{equation*} A \to ((\forall \alpha. B) \to C) \to C; \end{equation*}

the latter is stronger than the former, i.e., a term of the former type does not necessarily have the latter type, although the converse implication holds.

5.1 Extended language

The extension of $\lambda_{\text{eff}}$ and the polymorphic type system is shown in Figures 5 and 6, in which the extended part of the syntax is highlighted. Terms support: pairs; projections; injections; case expressions for sums; the nil constant; $ \mathsf{cons} $ expressions; case expressions for lists; and the fixed-point operator. A case expression matching injections $\mathsf{case} \, {M} \, \mathsf{of} \, \mathsf{inl} \, x \rightarrow {M_{{\mathrm{1}}}} {;} \, \mathsf{inr} \, y \rightarrow {M_{{\mathrm{2}}}}$ binds x in ${M_{{\mathrm{1}}}}$ and y in ${M_{{\mathrm{2}}}}$ ; a case expression matching lists $\mathsf{case} \, {M} \, \mathsf{of} \, \mathsf{nil} \, \rightarrow {M_{{\mathrm{1}}}} {;} \, \mathsf{cons} \, x \rightarrow {M_{{\mathrm{2}}}}$ binds x in ${M_{{\mathrm{2}}}}$ ; the fixed-point operator $\mathsf{fix} \, f {.} \lambda\! \, x {.} {M}$ binds f and x in M. Pairs, injections, and $ \mathsf{cons} $ expressions are values if their immediate subterms are also values. Types are extended with product types, sum types, and list types. The extension of evaluation contexts follows that of terms. For the semantics, the reduction rules for projections, case expressions, and the fixed-point operator are augmented. The extension of the polymorphic type system is also straightforward. Type containment is extended by adding six rules: the three rules on the left in Figure 6 are for compatibility and the three rules on the right are for distributing $\forall$ over immediate subcomponent types. All of the additional typing rules are standard.

Fig 5.

The extended part of the syntax and semantics.

Fig 6.

The extended part of the type system.

We also extend the polarity of the occurrences of a type variable. The polarity of the occurrences in type variables, function types, and polymorphic types is defined as in Definition 3 and that in product, sum, and list types is defined as follows.

Definition 5 (Polarity of type variable occurrence in product, sum, and list types).

The sets $ \mathit{ftv} ( A )^+ $ and $ \mathit{ftv} ( A )^- $ of type variables that occur positively and negatively, respectively, in type A are extended to product types, sum types, and list types, as follows.

\[\begin{array}{lll} \mathit{ftv} ( A \times B )^{\pm} &\stackrel{\rm \tiny def}{=}& \mathit{ftv} ( A )^{\pm} \, \mathbin{\cup} \, \mathit{ftv} ( B )^{\pm} \\ \mathit{ftv} ( A + B )^{\pm} &\stackrel{\rm \tiny def}{=}& \mathit{ftv} ( A )^{\pm} \, \mathbin{\cup} \, \mathit{ftv} ( B )^{\pm} \\ \mathit{ftv} ( A \, \mathsf{list} )^{\pm} &\stackrel{\rm \tiny def}{=}& \mathit{ftv} ( A )^{\pm} \\ \end{array} \]

The set $ \mathit{ftv} ( A )^+_\mathbf{ns} $ of type variables that occur nonstrictly positively in type A is extended as follows.

\[\begin{array}{lll} \mathit{ftv} ( A \times B )^+_\mathbf{ns} &\stackrel{\rm \tiny def}{=}& \mathit{ftv} ( A )^+_\mathbf{ns} \, \mathbin{\cup} \, \mathit{ftv} ( B )^+_\mathbf{ns} \\ \mathit{ftv} ( A + B )^+_\mathbf{ns} &\stackrel{\rm \tiny def}{=}& \mathit{ftv} ( A )^+_\mathbf{ns} \, \mathbin{\cup} \, \mathit{ftv} ( B )^+_\mathbf{ns} \\ \mathit{ftv} ( A \, \mathsf{list} )^+_\mathbf{ns} &\stackrel{\rm \tiny def}{=}& \mathit{ftv} ( A )^+_\mathbf{ns} \end{array} \]

The signature restriction for the extended language is defined as in Definition 4 except that the polarity of occurrences of type variables is defined by both of Definitions 3 and 5.

The type soundness of the extended language can be proven, as in Section 4.5, under the assumption that all operations conform to the signature restriction extended to product, sum, and list types. See the supplementary material for detail.

5.2 Examples

This section presents two operations that satisfy the signature restriction in the extended language.

The first example is select, which is an operation given in Section 2.1 for nondeterministic computation. The operation has the type signature $ \forall \, \alpha {.} \, \alpha \, \mathsf{list} \hookrightarrow \alpha $ , where the quantified type variable $\alpha$ occurs only at a strictly positive position in the parameter type $ \alpha \, \mathsf{list} $ and only at a positive position in the arity type $\alpha$ . Thus, select satisfies the signature restriction and, therefore, it can be safely called by any polymorphic expression.

The second example is from Leijen (Reference Leijen2017), who implemented parser combinators using algebraic effects and handlers. The effect for parsing provides a basic operation satisfy which has the type signature

\[ \forall \, \alpha {.} \, {(} \mathsf{str} \rightarrow {(} \alpha \times \mathsf{str} {)} + \mathsf{unit} {)} \hookrightarrow \alpha\]

where $ \mathsf{str} $ is the type of strings. This operation takes a parsing function of $ \mathsf{str} \rightarrow {(} \alpha \times \mathsf{str} {)} + \mathsf{unit} $ such that: the parsing function returns the unit value if an input string does not conform to the grammar; otherwise, it returns the parsing result of $\alpha$ and the unparsed, remaining string. The operation satisfy would return the result of parsing if it succeeds. For example, we can give satisfy a parsing function that returns the first character of a given input—and returns the unit value if the input is the empty string—as follows:

Here: $ \mathsf{length} $ is a function of $ \mathsf{str} \rightarrow \mathsf{int} $ that returns the length of a given string; $ \mathsf{first} $ is of $ \mathsf{str} \rightarrow \mathsf{char} $ ( $ \mathsf{char} $ is the type of characters) that returns the first character of a given string; and $ \mathsf{last} $ is of $ \mathsf{str} \rightarrow \mathsf{str} $ that returns the same string as an input except that it does not contain the first character of the input. In this example, the call of satisfy is of the type $ \mathsf{char} $ because the argument function is of the type $ \mathsf{str} \rightarrow {(} \mathsf{char} \times \mathsf{str} {)} + \mathsf{unit} $ , which requires the quantified type variable $\alpha$ to be instantiated to $ \mathsf{char} $ . The operation satisfy satisfies the signature restriction clearly. The quantified type variable $\alpha$ occurs only at a strictly positive position in the parameter type $ \mathsf{str} \rightarrow {(} \alpha \times \mathsf{str} {)} + \mathsf{unit} $ of the type signature, and it also occurs only at a positive position in the arity type $\alpha$ .

6.1 Effect system

Figure 7 shows only the key part of the effect system; the full definition is found in the supplementary material.

Fig 7.

The effect system (excerpt).

The type language includes effect information. Effects, ranged over by $\varepsilon$ , are finite sets of operations. Function types are augmented with effects that may be triggered in applying the functions of those types.

Typing judgments also incorporate effects. A term typing judgment $\Gamma \vdash {M} {:} A \, | \, \varepsilon$ asserts that M is a computation that produces a value of A possibly with effect $\varepsilon$ . A handler typing judgment $\Gamma \vdash {H} {:} A \, | \, \varepsilon \Rightarrow B \, | \, \varepsilon'$ asserts that H handles a computation that produces values of A possibly with effect $\varepsilon$ and the handling produces values of B possibly with effect $\varepsilon'$ . Type containment judgments $\Gamma \vdash A \sqsubseteq B$ and well-formedness judgments $\vdash \Gamma$ take the same forms as those of the polymorphic type system in Section 4.

Most of the typing rules for terms are almost the same as those of the polymorphic type system except that they take into account effect information. The rule shows how effects are incorporated into the typing rules: the effect triggered by a term is determined by its subterms. Besides, requires effect $\varepsilon'$ triggered by a function to be a subset of the effect $\varepsilon$ of the subterms. The rule is the key of the effect system, allowing a term to have a polymorphic type if it triggers only safe effects. The safety of an effect $\varepsilon$ is checked by the predicate $\mathit{SR} \, {(} \varepsilon {)}$ , which asserts that any operation in $\varepsilon$ satisfies the signature restriction for the type language in Figure 7; we will formalize $\mathit{SR} \, {(} \varepsilon {)}$ after explaining the type containment rules. A by-product of adopting is that the effect system incorporates the value restriction (Tofte, Reference Tofte1990) successfully: it allows values to have polymorphic types because the values perform no operation (thus, their effects can be the empty set $ \emptyset $ ) and $\mathit{SR} \, {(} \emptyset {)}$ obviously holds. The rule gives any effect $\varepsilon'$ to the fixed-point operator. This means that the fixed-point operator can be viewed as a pure computation because it only produces a lambda abstraction without triggering effects. The rule weakens the effect information of a term.

There are two rules for deriving a handler typing judgment $\Gamma \vdash {H} {:} A \, | \, \varepsilon \Rightarrow B \, | \, \varepsilon'$ . They state that the effect of a $ \mathsf{handle} $ – $ \mathsf{with} $ expression installing H consists of the operations that the handled expression may call but H does not handle and those that the return clause or some operation clause of H may call. The effect $\varepsilon \, \mathbin{\uplus} \, {\{} \mathsf{op} {\}}$ is the same as $\varepsilon \, \mathbin{\cup} \, {\{} \mathsf{op} {\}}$ except that it requires $\mathsf{op} \, \not\in \, \varepsilon$ .

Most of the type containment rules of the effect system are the same as those of the polymorphic type system. The exception is the rules for function types and , which are replaced by and to take into account effect information. The rule for deriving $\Gamma \vdash \forall \, \alpha {.} \, A \rightarrow ^{ \varepsilon } B \sqsubseteq A \rightarrow ^{ \varepsilon } \forall \, \alpha {.} \, B $ has an additional condition that $\mathit{SR} \, {(} \varepsilon {)}$ must hold. This condition originates from . The rule allows that, if a lambda abstraction $ \lambda\! \, x {.} {M}$ has a polymorphic type $ \forall \, \alpha {.} \, A \rightarrow ^{ \varepsilon } B $ , the body M may also have another polymorphic type $ \forall \, \alpha {.} \, B$ . In general, M may be a nonvalue term. In such a case, only justifies that M has a polymorphic type; however, to apply the effect $\varepsilon$ triggered by M has to meet $\mathit{SR} \, {(} \varepsilon {)}$ . This is the reason why requires that $\mathit{SR} \, {(} \varepsilon {)}$ hold.

Now, we formalize the predicate $\mathit{SR} \, {(} \varepsilon {)}$ , which states that any operation in $\varepsilon$ satisfies signature restriction extended by effect information. In what follows, we suppose the notions of positive/negative/nonstrictly positive occurrences of a type variable for the type language in Figure 7; they are defined naturally as in Definitions 3 and 5. In addition, we can decide whether a type occurs at a strictly positive position in a type by generalizing the polarity of the occurrences of type variables to those of types.

• • ${\{} \boldsymbol{ \alpha } {\}} \, \mathbin{\cap} \, \mathit{ftv} ( A )^+_\mathbf{ns} \, = \, \emptyset $ ;

• • ${\{} \boldsymbol{ \alpha } {\}} \, \mathbin{\cap} \, \mathit{ftv} ( B )^- \, = \, \emptyset $ ; and

• • for any function type $ C \rightarrow ^{ \varepsilon' } D $ occurring at a strictly positive position in the type A, if ${\{} \boldsymbol{ \alpha } {\}} \, \mathbin{\cap} \, \mathit{ftv} ( D ) \, \not= \, \emptyset $ , then $\mathit{SR} \, {(} \varepsilon' {)}$ .

The first and second conditions of Definition 6 are the same as those of Definition 4, signature restriction without effect information. The third condition is necessary to apply . The signature restriction in the polymorphic type system allows type variables $ \boldsymbol{ \alpha } $ in type signature $ \forall \, \boldsymbol{ \alpha } {.} \, A \hookrightarrow B $ to occur at a strictly positive position in the type A (see Definition 4). As discussed in Section 4.4.2, this capability originates from . In the effect system, the counterpart is applied to retain this capability, but requires the effect of a function type to satisfy $ \mathit{SR} $ . This is the reason why the signature restriction for the effect system imposes the third condition. Note that, if ${\{} \boldsymbol{ \alpha } {\}} \, \mathbin{\cap} \, \mathit{ftv} ( D ) \, = \, \emptyset $ (as well as ${\{} \boldsymbol{ \alpha } {\}} \, \mathbin{\cap} \, \mathit{ftv} ( C ) \, = \, \emptyset $ ), then we can derive $\Gamma \vdash \forall \, \boldsymbol{ \alpha } {.} \, C \rightarrow ^{ \varepsilon' } D \sqsubseteq C \rightarrow ^{ \varepsilon' } \forall \, \boldsymbol{ \alpha } {.} \, D $ without . Thus, the third condition does not require $\mathit{SR} \, {(} \varepsilon' {)}$ if ${\{} \boldsymbol{ \alpha } {\}} \, \mathbin{\cap} \, \mathit{ftv} ( D ) \, = \, \emptyset $ .

We finally state soundness of the effect system, which ensures that a well-typed program handles all the operations performed at run time. We prove it by progress and subject reduction; their formal statements and proofs are found in the supplementary material.

6.2 Example

The effect system allows us to use both safe and unsafe effects in a single program. For example, let us consider the following program (which can be represented in $\lambda_{\text{eff}}^{\text{ext}}$ ).

This example would be rejected if we were to enforce all operations to follow the signature restriction as in Section 4 because it uses the unsafe operation get_id. By contrast, the effect system accepts it because: the polymorphic expression calls no operation (because it is a value) and #select([ $\lambda$ x. x; f]) calls only select, which satisfies the signature restriction, during the evaluation; therefore, they can have the polymorphic type by . Note that the effect system still rejects the counterexample given in Section 2.3 because it disallows polymorphic expressions to call operations that do not satisfy the signature restriction, such as get_id.

6.3 Alternative designs

When defining the effect system presented thus far, we kept simplicity in mind, which affected the design of the effect system. Specifically, we decided that 1) the type signatures of operations are assumed to be assigned globally and 2) type containment does not involve subeffecting (it is used only for type instantiation). This section informally discusses the alternatives of these decisions: local assignment of type signatures and type containment with subeffecting.

6.3.1 Local assignment of type signatures

In the formalized system, effects are sets only of operations, and their type signatures are uniquely determined by metafunction $ \mathit{ty} $ . We call this assignment of type signatures global. The global type signature assignment models the treatment of effects in programming languages, such as Koka (Leijen, Reference Leijen2023) and Frank (Lindley et al., Reference Lindley, McBride, McLaughlin and Convent2022), where every effect operation has to be declared with a type signature before used.

An alternative is to represent effects as sets of pairs of an operation and its type signature (Kammar et al., Reference Kammar, Lindley and Oury2013), as

\[ \varepsilon_\mathrm{local} ~{::=}~ \{ \mathsf{op}_{{\mathrm{1}}} : \forall \, \boldsymbol{ \alpha_{{\mathrm{1}}} }^{ {\mathit{I}_{\mathrm{1}}} } {.} \, A_{{\mathrm{1}}} \hookrightarrow B_{{\mathrm{1}}} , ~\dots, ~\mathsf{op}_{{n}} : \forall \,\boldsymbol{ \alpha_{{n}} } ^{ {\mathit{I}_{\mathrm{n}}} } {.} \, A_{{n}} \hookrightarrow B_{{n}} \} ~.\]

In this representation, we can assign different type signatures to different occurrences of the same operation. Hence, we call this type assignment local. For example, consider the following function application:

where the function part supposes operation $\mathsf{op}$ ’s type signature to be $ \mathsf{int} \hookrightarrow A $ for some type A, while the argument part supposes it to be $ \mathsf{bool} \hookrightarrow B $ for some type B. The handlers ${H_{{\mathrm{1}}}}$ and ${H_{{\mathrm{2}}}}$ should involve operation clauses conforming to these type signatures, respectively. More interestingly, the same operation can be given different type signatures per occurrence even in the same effect. For example, consider the following effect:

\[ \{ \mathsf{op} : A_{{\mathrm{1}}} \hookrightarrow {(} B_{{\mathrm{1}}} \rightarrow ^{ \{ \mathsf{op} : C_{{\mathrm{1}}} \hookrightarrow C_{{\mathrm{2}}} \} } B_{{\mathrm{2}}} {)} \} ~.\]

It states that operation $\mathsf{op}$ returns a function of the type $ B_{{\mathrm{1}}} \rightarrow ^{ \{ \mathsf{op} : C_{{\mathrm{1}}} \hookrightarrow C_{{\mathrm{2}}} \} } B_{{\mathrm{2}}} $ , that is, when the returned function is applied and then invokes operation $\mathsf{op}$ with an argument of type $C_{{\mathrm{1}}}$ , the caller expects the operation to return a value of type $C_{{\mathrm{2}}}$ . One critical difference between the local and global assignment of type signatures is in program termination: one can write divergent programs under the global assignment, whereas the local assignment can guarantee well-typed programs terminating (Kammar and Pretnar, Reference Kammar and Pretnar2017). The local assignment is employed by, e.g., the links programming language (The Links team, 2022).

To adapt the signature restriction to the local type signature assignment, we need to make changes to the definitions of the polarities of type variables, type containment’s distributive law, and type generalization, in addition to a minor change that the type signature of an operation is found in an effect, not assigned by the metafunction $ \mathit{ty} $ . We describe the details of the three major changes below, but it is left open whether only these changes (including the minor one) can ensure soundness of an effect system that assigns type signatures locally.

Change 1: Polarities of type variables.

Effects in the local assignment may contain free type variables. Therefore, we need to extend the polarities of type variables to take effects into account, as follows:

\[\begin{array}{lll} \mathit{ftv} ( A \rightarrow ^{ \varepsilon_\mathrm{local} } B )^{\pm} &\stackrel{\rm \tiny def}{=}& \mathit{ftv} ( A )^{\mp} \, \mathbin{\cup} \, \mathit{ftv} ( B )^{\pm} \, \mathbin{\cup} \, \mathit{ftv} ( \varepsilon_\mathrm{local} )^{\pm} \\[.5ex] \mathit{ftv} ( \varepsilon_\mathrm{local} )^{\pm} &\stackrel{\rm \tiny def}{=}& {(} {(} \mathit{ftv} ( A_{{\mathrm{1}}} )^{\mp} \, \mathbin{\cup} \, \mathit{ftv} ( B_{{\mathrm{1}}} )^{\pm} {)} \, \mathbin{\backslash} \, {\{} \boldsymbol{ \alpha_{{\mathrm{1}}} }^{ {\mathit{I}_{\mathrm{1}}} } {\}} {)} \,\cup\, \dots \,\cup\, \\ && {(} {(} \mathit{ftv} ( A_{{n}} )^{\mp} \, \mathbin{\cup} \, \mathit{ftv} ( B_{{n}} )^{\pm} {)} \, \mathbin{\backslash} \, {\{} \boldsymbol{ \alpha_{{n}} }^{ {\mathit{I}_{\mathrm{n}}} } {\}} {)} \\[1ex] \mathit{ftv} ( A \rightarrow ^{ \varepsilon_\mathrm{local} } B )^+_\mathbf{ns} &\stackrel{\rm \tiny def}{=}& \mathit{ftv} ( A )^- \, \mathbin{\cup} \, \mathit{ftv} ( B )^+_\mathbf{ns} \, \mathbin{\cup} \, \mathit{ftv} ( \varepsilon_\mathrm{local} )^+_\mathbf{ns} \\ \mathit{ftv} ( \varepsilon_\mathrm{local} )^+_\mathbf{ns} &\stackrel{\rm \tiny def}{=}& {(} {(} \mathit{ftv} ( A_{{\mathrm{1}}} )^- \, \mathbin{\cup} \, \mathit{ftv} ( B_{{\mathrm{1}}} )^+_\mathbf{ns} {)} \, \mathbin{\backslash} \, {\{} \boldsymbol{ \alpha_{{\mathrm{1}}} }^{ {\mathit{I}_{\mathrm{1}}} } {\}} {)} \,\cup\, \dots \,\cup\, \\ && {(} {(} \mathit{ftv} ( A_{{n}} )^- \, \mathbin{\cup} \, \mathit{ftv} ( B_{{n}} )^+_\mathbf{ns} {)} \, \mathbin{\backslash} \, {\{}\boldsymbol{ \alpha_{{n}} }^{ {\mathit{I}_{\mathrm{n}}} } {\}} {)} \\ \end{array}\]

where $\varepsilon_\mathrm{local}$ is supposed to be $\{ \mathsf{op}_{{\mathrm{1}}} : \forall \, \boldsymbol{ \alpha_{{\mathrm{1}}} }^{ {\mathit{I}_{\mathrm{1}}} } {.} \, A_{{\mathrm{1}}} \hookrightarrow B_{{\mathrm{1}}} , ~\dots, ~\mathsf{op}_{{n}} : \forall \, \boldsymbol{ \alpha_{{n}} }^{ {\mathit{I}_{\mathrm{n}}} } {.} \, A_{{n}} \hookrightarrow B_{{n}} \}$ .

Change 2: Type containment’s distributive law.

The distributive law can be modified so that $\forall$ quantifying a function type moves not only to its codomain type but also to the arity types of the type signatures in its latent effect. Namely, the adapted distributive law can be given as

\[ \frac{\begin{array}{c} { \varepsilon_\mathrm{local} = \{ \mathsf{op}_{{\mathrm{1}}} : \forall \, \boldsymbol{ \beta_{{\mathrm{1}}} }^{ {\mathit{I}_{\mathrm{1}}} } {.} \, C_{{\mathrm{1}}} \hookrightarrow D_{{\mathrm{1}}} , ~\dots, ~\mathsf{op}_{{n}} : \forall \, \boldsymbol{ \beta_{{n}} }^{ {\mathit{I}_{\mathrm{n}}} } {.} \, C_{{n}} \hookrightarrow D_{{n}} \}}\\ { \varepsilon_\mathrm{local}' = \{ \mathsf{op}_{{\mathrm{1}}} : \forall \, \boldsymbol{ \beta_{{\mathrm{1}}} } ^{ {\mathit{I}_{\mathrm{1}}} } {.} \, C_{{\mathrm{1}}} \hookrightarrow \forall \, \alpha {.} \, D_{{\mathrm{1}}} , ~\dots, ~\mathsf{op}_{{n}} : \forall \, \boldsymbol{ \beta_{{n}} }^{ {\mathit{I}_{\mathrm{n}}} } {.} \, C_{{n}} \hookrightarrow \forall \, \alpha {.} \, D_{{n}} \}}\\ { \vdash \Gamma \quad \alpha \, \not\in \, \mathit{ftv} ( A ) \cup \mathit{ftv} ( C_{{\mathrm{1}}} ) \cup \dots \cup \mathit{ftv} ( C_{{n}} ) \quad \mathit{SR} \, {( \varepsilon_{\mathrm{local}} )} }\end{array}}{\Gamma \vdash \forall \, \alpha {.} \, A \rightarrow ^{ \varepsilon_{\mathrm{local}} } B \sqsubseteq A \rightarrow ^{ \varepsilon_{\mathrm{local}}' } \forall \, \alpha {.} \, B}\]

First, this rule means that, as , given a function of a type $ \forall \, \alpha {.} \, A \rightarrow ^{ \varepsilon_\mathrm{local} } B $ , its body can be regarded as a polymorphic computation of the type $ \forall \, \alpha {.} \, B$ . Suppose that the body performs operation, say, $\mathsf{op}_{{i}}$ . The effect $\varepsilon_\mathrm{local}$ in the LHS type requires $\mathsf{op}_{{i}}$ to return a value of type $D_{{i}}$ where type variable $\alpha$ has been replaced by, say, a type A’, while the effect $\varepsilon_\mathrm{local}'$ in the RHS type means that an implementation of the operation has to return a polymorphic value of the type $ \forall \, \alpha {.} \, D_{{i}}$ . This gap is bridged as follows: given a value of type $ \forall \, \alpha {.} \, D_{{i}}$ , the body can instantiate it with the type A’ used to instantiate the body. Because the instantiated value should be of type $ D [ A' {/} \alpha ] $ , it meets the requirement of the LHS type.

The above rule can be generalized slightly using existential types: when existential types of the form $ \text{}$ $ \, \alpha {.} \, A$ are available, we can allow $\alpha$ to occur in the parameter types $C_{{\mathrm{1}}}, \dots, C_{{n}}$ and instead set the type signature of each $\mathsf{op}_{{i}}$ in $\varepsilon_\mathrm{local}'$ to $ \forall \, \boldsymbol{ \beta_{{i}} } ^{ \text{I}_{i}}$ $ {.} \, {(} \text{}$ $ \, \alpha {.} \, C_{{i}} {)} \hookrightarrow \forall \, \alpha {.} \, D_{{i}} $ . Because an operation clause conforming to this type signature must be independent of the concrete type for $\alpha$ in $C_{{i}}$ and return a value polymorphic over $\alpha$ in $D_{{i}}$ , it can interpret any call to $\mathsf{op}_{{i}}$ in the function body no matter what type A’ is used to instantiate the body.

The two presented variants of the distributive law are designed so that the latent effect $\varepsilon_\mathrm{local}'$ satisfies the signature restriction. However, it is open whether such a property is necessary to prove type soundness. If it turns out to be unnecessary, the typing rule could be further generalized by setting the type signature of $\mathsf{op}_{{i}}$ in $\varepsilon_\mathrm{local}'$ to $ \forall \, \boldsymbol{ \beta_{{i}} }^{ \text{} }$ I_i $ {.} \forall \, \alpha {.} \, ( C_{{i}} \hookrightarrow D_{{i}} ) $ . Note that $ \forall \, \boldsymbol{ \beta_{{i}} }^{ \text{I}_{i}}$ $ {.} \forall \, \alpha {.} \, ( C_{{i}} \hookrightarrow D_{{i}} ) $ invalidates the signature restriction if $\alpha$ occurs nonstrictly positively in $C_{{i}}$ or negatively in $D_{{i}}$ . Because $ \forall \, \boldsymbol{ \beta_{{i}} }^{ \text{I}_{i}}$ $ {.} \, {(} \text{}$ $ \, \alpha {.} \, C_{{i}} {)} \hookrightarrow \forall \, \alpha {.} \, D_{{i}} $ is a “subtype” of $ \forall \,\boldsymbol{ \beta_{{i}} }^{ \text{ I}_{i}}$ $ \forall \,\boldsymbol{ \beta}_{i} ^{{I}_{i}}$ , the former imposes more restrictions on operation clauses for $\mathsf{op}_{{i}}$ than the latter.

Change 3: Type generalization.

A simple way to adapt type generalization to the local assignment is to allow type generalization only when effects do not refer to type variables being quantified:

\[ \frac{ \Gamma {,} \alpha \vdash {M} {:} A \, | \, \varepsilon_\mathrm{local} \quad \mathit{SR} \, {(} \varepsilon_\mathrm{local} {)} \quad \alpha \, \not\in \, \mathit{ftv} ( \varepsilon_\mathrm{local} ) \\}{\Gamma \vdash {M} {:} \forall \, \alpha {.} \, A \, | \, \varepsilon_\mathrm{local} }\]

where $ \mathit{ftv} ( \varepsilon_\mathrm{local} ) $ is the set of type variables that occur free in $\varepsilon_\mathrm{local}$ . This rule can also be generalized to allow $\alpha$ to occur in $\varepsilon_\mathrm{local}$ , as discussed in the previous paragraph, by assigning M an effect $\varepsilon_\mathrm{local}'$ where: the parameter and arity types of the type signatures quantify $\alpha$ existentially and universally, respectively; or the type signatures universally quantify $\alpha$ (if $\varepsilon_\mathrm{local}'$ does not have to satisfy the signature restriction to show type soundness).

8.1 Restriction for the use of effects in polymorphic type assignment

The problem that type safety is broken in naively combining polymorphic effects and polymorphic type assignment was initially discovered in a language with polymorphic references (Gordon et al., Reference Gordon, Milner and Wadsworth1979) and later in one with polymorphic control operators (Harper and Lillibridge, Reference Harper and Lillibridge1991, Reference Harper and Lillibridge1993). Researchers have developed many approaches to reconcile these conflicting features thus far (Tofte, Reference Tofte1990; Leroy and Weis, Reference Leroy and Weis1991; Appel and MacQueen, Reference Appel and MacQueen1991; Hoang et al., Reference Hoang, Mitchell and Viswanathan1993;Wright, Reference Wright1995; Garrigue, Reference Garrigue2004; Asai and Kameyama, Reference Asai and Kameyama2007; Sekiyama and Igarashi, Reference Sekiyama and Igarashi2019).

A major direction shared among them is to prevent the generalization of type variables assigned to an expression if the type variables are used to instantiate polymorphic effects triggered by the expression. Leroy and Weis (Reference Leroy and Weis1991) called such type variables dangerous. The value restriction (Tofte, Reference Tofte1990;Wright, Reference Wright1995), which allows only syntactic values to be polymorphic, is justified by this idea because these values trigger no effect and therefore no dangerous type variable exists. Similarly, Asai and Kameyama (Reference Asai and Kameyama2007) and Leijen (Reference Leijen2017) allowed only observationally pure expressions to be polymorphic. Tofte (Reference Tofte1990) proposed another approach that classifies type variables into applicative ones, which cannot be used to instantiate effects, and imperative ones, which may be used, and allows the generalization of only applicative type variables. Weak polymorphism (Appel and MacQueen, Reference Appel and MacQueen1991; Hoang et al., Reference Hoang, Mitchell and Viswanathan1993) extends this idea by assigning to a type variable the number of function applications necessary to trigger effects instantiated with the type variable. If the numbers assigned to type variables are positive, effects instantiated with the type variables are not triggered; therefore, they are not dangerous and can be generalized safely. Leroy and Weis (Reference Leroy and Weis1991) prevented the generalization of dangerous type variables by making the type information of free variables in closures accessible. These approaches focused on a specific effect (especially, the ML-style reference effect), but they can be applied to other effects as well.

One view for relating our work to these prior works is that, while the prior works suppose that no dangerous type variables can be generalized safely, our work discovers that they can be if the polymorphic effect of interest meets the signature restriction. Note that the assumption of the prior works is natural because they focus on the reference effect, which does not comply with the signature restriction. To see it, assume that we are given a type constructor $ A \, \mathsf{ref} $ for references pointing to values of type A. We also suppose that the reference effect supports an operation to create a new reference cell, and it is equipped with type signature $\forall \alpha. \alpha \hookrightarrow \alpha \, \mathsf{ref} $ . Because the polarities of the type variables appearing in a reference type $ A \, \mathsf{ref} $ are invariant (i.e., positive and negative), the type signature does not meet the signature restriction.

Garrigue (Reference Garrigue2004) proposed the relaxed value restriction, which allows the generalization of type variables assigned to an expression if the type variables occur only at positive positions in the type of the expression. The polarity condition on generalized type variables makes it possible to use the empty type as a surrogate of the type variables and, as a result, prevents instantiating effects with the type variables. The relaxed value restriction is similar to signature restriction in that both utilize the polarity of type variables. In fact, the strong signature restriction, introduced in Section 2.4, is explainable by using the empty type ${\mathsf{zero}}$ and subtyping $<:$ for it (i.e., deeming ${\mathsf{zero}}$ a subtype of any type) as in the relaxed value restriction. First, let us recall the key idea of the strong signature restriction: it is to rewrite an operation call $\Lambda \beta_1 \dots \beta_n.\,$ #op $\{C\}$ (v) for op : $\forall \alpha.\, A \hookrightarrow B$ to $\Lambda \beta_1 \dots \beta_n.\,$ #op $\{ \forall \beta_1 \dots \beta_n. \, C\}$ (v) to close the type argument C and to use provable type containment judgments $A[C/\alpha] \mathrel{ \sqsubseteq } A[\forall \beta_1 \dots \beta_n.\,C/\alpha]$ and $B[\forall \beta_1 \dots \beta_n.\,C/\alpha] \mathrel{ \sqsubseteq } B[C/\alpha]$ for typing the latter term. We can rephrase this idea with ${\mathsf{zero}}$ , instead of $\forall \beta_1 \dots\beta_n. \, C$ , as follows: the operation call is rewritten to $\Lambda\beta_1 \dots \beta_n.\,$ #op $\{ \mathsf{zero} \}$ (v), and this term can be typed by using the subtyping judgments $A[C/\alpha] \mathrel{<:} A[{\mathsf{zero}}/\alpha]$ and $B[{\mathsf{zero}}/\alpha] \mathrel{<:} B[C/\alpha]$ , which are provable owing to the polarity condition of the strong signature restriction (i.e., the type variable $\alpha$ occurs only negatively in the type A and only positively in the type B). However, this argument does not extend to the (non-strong) signature restriction because it allows the bound type variable $\alpha$ to occur at strictly positive positions in the parameter type A and then $A[C/\alpha]\mathrel{<:} A[{\mathsf{zero}}/\alpha]$ no longer holds. Thus, our technical contributions include the findings that the type argument C and value argument v can be closed by quantifying them and that $\forall \beta_1 \dots \beta_n.\,A[C/\alpha] \mathrel{ \sqsubseteq } A[\forall \beta_1 \dots \beta_n.\,C/\alpha]$ is provable by type containment, where the distributive law plays a key role. This change renders the signature restriction quite permissive.

Sekiyama and Igarashi (Reference Sekiyama and Igarashi2019) followed another line of research: they restricted the definitions of effects instead of their usage. As discussed in Section 7, their type system can be explained in our type system without effects. Furthermore, we provide an effect system that allows the use of both of the operations that satisfy and those that do not satisfy the restriction criterion—inasmuch as they are performed appropriately. The effect system utilizes the benefit of the signature restriction that it only depends on the type interfaces of effects.

Effect systems have been used to safely introduce effects in polymorphic type assignment thus far. Asai and Kameyama (Reference Asai and Kameyama2007) and Leijen (Reference Leijen2017) utilized effect systems for the control operators shift/reset (Danvy and Filinski, Reference Danvy and Filinski1990) and algebraic effects and handlers, respectively, to ensure that polymorphic expressions are observationally pure. Kammar and Pretnar (Reference Kammar and Pretnar2017) proposed an effect system for parameterized algebraic effects, which are declared with type parameters and invoked with type arguments. Unlike polymorphic effects, parameterized effects invoked with different type arguments are deemed different. Kammar and Pretnar utilized the effect system to prevent the generalization of the type variables involved by type arguments of parameterized effects.

8.2 User-defined effects

Our work employs algebraic effects and handlers as a technical development to describe a variety of effects. Algebraic effects were originally proposed as a denotational framework to describe the meaning of an effect by separating the interface of an effect, which is given by a set of operations, and its interpretation, which is given by the equational theory over the operations (Plotkin and Power, Reference Plotkin and Power2003). Plotkin and Pretnar (Reference Plotkin and Pretnar2013, Reference Plotkin and Pretnar2009) introduced effect handlers in order to represent the semantics of exception handling in an equational theory. The idea of separating an effect interface and its interpretation makes it possible to handle user-defined effects in a modular way and encourages the emergence of languages equipped with algebraic effect handlers, such as Eff (Bauer and Pretnar, Reference Bauer and Pretnar2015), Koka (Leijen, Reference Leijen2017), Frank (Lindley et al., Reference Lindley, McBride and McLaughlin2017), and Multicore OCaml (Dolan et al., Reference Dolan, Eliopoulos, Hillerström, Madhavapeddy, Sivaramakrishnan and White2017). We also utilize the separation and restrict only effect interfaces in order to achieve type safety in polymorphic type assignment.

Another approach to user-defined effects is to use control operators, which enable programmers to make access to continuations. Many control operators have been developed thus far—e.g., call/cc (Clinger et al., Reference Clinger, Friedman, Wand, Nivat and Reynolds1985), control/prompt (Felleisen, Reference Felleisen1988), shift/reset (Danvy and Filinski, Reference Danvy and Filinski1990), fcontrol/run (Sitaram, Reference Sitaram1993), and cupto/prompt (Gunter et al., Reference Gunter, Rémy and Riecke1995). These operators are powerful and generic, but, in return for that, it is unsafe to naively combine them with polymorphic type assignment (Harper and Lillibridge, Reference Harper and Lillibridge1993). They do not provide a means to assign fine-grained type interfaces to individual effects. Thus, it is not clear how to apply the idea of signature restriction for the effects implemented by control operators.

Monads can also express the interpretation of an effect in a denotational manner (Moggi, Reference Moggi1991) and have been used as a long-established, programmable means for user-defined effects (Wadler, Reference Wadler1992; Peyton Jones and Wadler, Reference Peyton Jones and Wadler1993). Filinski (Reference Filinski2010) extracted the essence of monadic effects and proposed a language equipped with a type system and an operation semantics for them. We expect our idea of restriction on effect interfaces to be applicable to monadic effects as well, but for that we would first need to consider how to introduce polymorphic effects into a monadic language because Filinski’s language supports parametric effects but not polymorphic effects.