Manifest Contracts with Intersection Types

Yuki Nishida; Atsushi Igarashi

arXiv:1908.03010·cs.PL·September 6, 2019

Manifest Contracts with Intersection Types

Yuki Nishida, Atsushi Igarashi

PDF

Open Access

TL;DR

This paper introduces PCFvΔH, a typed functional calculus with intersection types and manifest contracts, addressing the challenge of runtime checking for conjunctive contracts in a typed setting.

Contribution

It extends the Δ-calculus to include manifest contracts with intersection types, providing formal properties and ensuring runtime checks do not alter computation.

Findings

01

Formal definition of PCFvΔH with intersection types

02

Proof of preservation, progress, and value inversion

03

Runtime checking does not affect computation

Abstract

We present a manifest contract system PCFv $Δ$ H with intersection types. A manifest contract system is a typed functional calculus in which software contracts are integrated into a refinement type system and consistency of contracts is checked by combination of compile- and run-time type checking. Intersection types naturally arise when a contract is expressed by a conjunction of smaller contracts. Run-time contract checking for conjunctive higher-order contracts in an untyped language has been studied but our typed setting poses an additional challenge due to the fact that an expression of an intersection type $τ_{1} \land τ_{2}$ may have to perform different run-time checking whether it is used as $τ_{1}$ or $τ_{2}$ . We build PCFv $Δ$ H on top of the $Δ$ -calculus, a Church-style intersection type system by Liquori and Stolze. In the $Δ$ -calculus, a canonical…

Equations42

(even \to even \to even) \land (even \to odd \to odd) \land (odd \to even \to odd) \land (odd \to odd \to even)

(even \to even \to even) \land (even \to odd \to odd) \land (odd \to even \to odd) \land (odd \to odd \to even)

(x : nat) \to (y : nat) \to {z : nat ∣

(x : nat) \to (y : nat) \to {z : nat ∣

then (if evenp y then evenp z else oddp z)

else (if evenp y then oddp z else evenp z)}

((int \to {x : int ∣ x \neq = 0}) \to {z : int ∣ z = 1}) \land ((int \to int) \to {z : int ∣ z = 0})

((int \to {x : int ∣ x \neq = 0}) \to {z : int ∣ z = 1}) \land ((int \to int) \to {z : int ∣ z = 0})

let s u c c^{'} : odd \to even = λ x . succ (x) .

let s u c c^{'} : odd \to even = λ x . succ (x) .

let s u c c^{'} : odd \to even = λ x : odd . (succ ((x : odd \Rightarrow nat)) : nat \Rightarrow even) .

let s u c c^{'} : odd \to even = λ x : odd . (succ ((x : odd \Rightarrow nat)) : nat \Rightarrow even) .

let s u c c^{'} : (odd \to even) \land (even \to odd) = λ x . succ (x) .

let s u c c^{'} : (odd \to even) \land (even \to odd) = λ x . succ (x) .

⟨ λ x : even . x, λ x : odd . x ⟩

⟨ λ x : even . x, λ x : odd . x ⟩

let s u c c^{'} : (odd \to even) \land (even \to odd) = ⟨ λ x : odd . (succ ((x : odd \Rightarrow nat)) : nat \Rightarrow even), λ x : even . (succ ((x : even \Rightarrow nat)) : nat \Rightarrow odd)⟩

let s u c c^{'} : (odd \to even) \land (even \to odd) = ⟨ λ x : odd . (succ ((x : odd \Rightarrow nat)) : nat \Rightarrow even), λ x : even . (succ ((x : even \Rightarrow nat)) : nat \Rightarrow odd)⟩

(V : σ \Rightarrow τ_{1} \land τ_{2}) ⟶ ⟨(V : σ \Rightarrow τ_{1}), (V : σ \Rightarrow τ_{2})⟩

(V : σ \Rightarrow τ_{1} \land τ_{2}) ⟶ ⟨(V : σ \Rightarrow τ_{1}), (V : σ \Rightarrow τ_{2})⟩

(V : σ_{1} \land σ_{2} \Rightarrow τ) ⟶ (π_{1} (V) : σ_{1} \Rightarrow τ)

(V : σ_{1} \land σ_{2} \Rightarrow τ) ⟶ (π_{1} (V) : σ_{1} \Rightarrow τ)

(V : σ_{1} \land σ_{2} \Rightarrow τ) ⟶ (π_{2} (V) : σ_{2} \Rightarrow τ)

(λ f : nat \to nat . f 0 + f 1) M_{cast}

(λ f : nat \to nat . f 0 + f 1) M_{cast}

M_{cast} := (V : (even \to nat) \land (odd \to nat) \Rightarrow nat \to nat) .

M_{cast} := (V : (even \to nat) \land (odd \to nat) \Rightarrow nat \to nat) .

V_{cast} := ⟨ ⟨ V : (even \to nat) \land (odd \to nat) \Rightarrow nat \to nat ⟩ ⟩,

V_{cast} := ⟨ ⟨ V : (even \to nat) \land (odd \to nat) \Rightarrow nat \to nat ⟩ ⟩,

(λ f : nat \to nat . f 0 + f 1) M_{cast}

(λ f : nat \to nat . f 0 + f 1) M_{cast}

⟶

⟶

⟶^{*}

⟶^{*}

(V : σ_{1} \to σ_{2} \Rightarrow τ_{1} \to τ_{2}) ⟶ λ x : τ_{1} . (V (x : τ_{1} \Rightarrow σ_{1}) : σ_{2} \Rightarrow τ_{2}) .

(V : σ_{1} \to σ_{2} \Rightarrow τ_{1} \to τ_{2}) ⟶ λ x : τ_{1} . (V (x : τ_{1} \Rightarrow σ_{1}) : σ_{2} \Rightarrow τ_{2}) .

(0 : nat \Rightarrow {x : nat ∣ x > 0}) + 1 ⟶

(0 : nat \Rightarrow {x : nat ∣ x > 0}) + 1 ⟶

⟶

⟶

⟶

Peer Reviews

No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.

Videos

No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.

Taxonomy

TopicsLogic, programming, and type systems · Formal Methods in Verification · Security and Verification in Computing

Full text

11institutetext: Graduate School of Informatics, Kyoto University, Kyoto, Japan

11email: {nishida,igarashi}@fos.kuis.kyoto-u.ac.jp

Manifest Contracts with Intersection Types

Yuki Nishida

Atsushi Igarashi

0000-0002-5143-9764

Abstract

We present a manifest contract system PCFv $\Delta_{\mathrm{H}}$ with intersection types. A manifest contract system is a typed functional calculus in which software contracts are integrated into a refinement type system and consistency of contracts is checked by combination of compile- and run-time type checking. Intersection types naturally arise when a contract is expressed by a conjunction of smaller contracts. Run-time contract checking for conjunctive higher-order contracts in an untyped language has been studied but our typed setting poses an additional challenge due to the fact that an expression of an intersection type $\tau_{{\mathrm{1}}}\wedge\tau_{{\mathrm{2}}}$ may have to perform different run-time checking whether it is used as $\tau_{{\mathrm{1}}}$ or $\tau_{{\mathrm{2}}}$ .

We build PCFv $\Delta_{\mathrm{H}}$ on top of the $\Delta$ -calculus, a Church-style intersection type system by Liquori and Stolze. In the $\Delta$ -calculus, a canonical expression of an intersection type is a strong pair, whose elements are the same expressions except for type annotations. To address the challenge above, we relax strong pairs so that expressions in a pair are the same except for type annotations and casts, which are a construct for run-time checking.

We give a formal definition of PCFv $\Delta_{\mathrm{H}}$ and show its basic properties as a manifest contract system: preservation, progress, and value inversion. Furthermore, we show that run-time checking does not affect essential computation.

1 Introduction

Manifest contract systems [12, 31, 25, 24, 26, 1, 11, 13, 10, 15, 19], which are typed functional calculi, are one discipline handling software contracts [18]. The distinguishing feature of manifest contract systems is that they integrate contracts into a type system and guarantee some sort of satisfiability against contracts in a program as type soundness. Specifically, a contract is embedded into a type by means of refinement types of the form $\{x\mathord{:}\tau\mid M\}$ , which represents the subset of the underlying type $\tau$ such that the values in the subset satisfy the predicate $M$ , which can be an arbitrary Boolean expression in the programming language. Using the refinement types, for example, we can express the contract of a division function, which would say “… the divisor shall not be zero …”, by the type $\mathtt{int}\rightarrow\{x\mathord{:}\mathtt{int}\mid x\neq 0\}\rightarrow\mathtt{int}$ . In addition to the refinement types, manifest contract systems are often equipped with dependent function types in order to express more detailed contracts. A dependent function type, written $(x\mathord{:}\sigma)\rightarrow\tau$ in this paper, is a type of a function which takes one argument of the type $\sigma$ and returns a value of the type $\tau$ ; the distinguished point from ordinary function types is that $\tau$ can refer to the given argument represented by $x$ . Hence, for example, the type of a division function can be made more specific like $(x\mathord{:}\mathtt{int})\rightarrow(y\mathord{:}\{x^{\prime}\mathord{:}\mathtt{int}\mid x^{\prime}\neq 0\})\rightarrow\{z\mathord{:}\mathtt{int}\mid x=z\times y\}$ . (Here, for simplicity, we ignore the case where devision involves a remainder, though it can be taken account into by writing a more sophisticated predicate.)

A manifest contract system checks a contract dynamically to achieve its goal—as many correct programs as possible can be compiled and run; while some studies [23, 28, 16, 27, 33, 30], which also use a refinement type system, check contract satisfaction statically but with false positives and/or restriction on predicates. The checks are done in the form of explicit casts of the form $(M:\sigma\Rightarrow\tau)$ ; where $M$ is a subject, $\sigma$ is a source type (namely the type of $M$ ), and $\tau$ is a target type.111Many manifest contract systems put a unique label on each cast to distinguish which cast fails, but we omit them for simplicity. A cast checks whether the value of $M$ can have the type $\tau$ . If the check fails, the cast throws an uncatchable exception called blame, which stands for contract violation. So, the system does not guarantee the absence of contract violations statically, but it guarantees that the result of successful execution satisfies the predicate of a refinement type in the program’s type. This property follows subject reduction and a property called value inversion [26]—if a value $V$ has a type $\{x\mathord{:}\tau\mid M\}$ , then the expression obtained by substituting $V$ for $x$ in $M$ is always evaluated into $\mathtt{true}$ .

1.1 Motivation

The motivation of the integration of intersection types is to enrich the expressiveness of contracts by types. It naturally arises when we consider a contract stated in a conjunctive form [9, 14, 3]. Considering parities (even/odd) of integers, for example, we can state a contract of the addition as a conjunctive form; that is

“An even integer is returned if both given arguments are even integers; and an odd integer is returned if the first given argument is even integer and the second given argument is odd integer; and …”

Using intersection types, we can write the contract as the following type.222 $\mathtt{even}\mathrel{:=}\{x\mathord{:}\mathtt{nat}\mid x\,\mathtt{mod}\,2=0\}\quad\mathtt{odd}\mathrel{:=}\{x\mathord{:}\mathtt{nat}\mid x\,\mathtt{mod}\,2=1\}$

[TABLE]

In fact, a semantically equivalent contract could be expressed by using dependent function types found in existing systems as follows, where $\mathtt{evenp}\mathrel{:=}\lambda x\mathord{:}\mathtt{nat}.x\,\mathtt{mod}\,2=0$ and $\mathtt{oddp}\mathrel{:=}\lambda x\mathord{:}\mathtt{nat}.x\,\mathtt{mod}\,2=1$ .

[TABLE]

Thus, one might think it is just a matter of taste in how contracts are represented. However, intersection types are more expressive, that is, there are contracts that are hard to express in existing manifest contract systems. Consider the following (a bit contrived) contract for a higher-order function.

[TABLE]

The result type depends on input as the parity contract does. This time, however, it cannot be written with a dependent function type; there is no obvious way to write a predicate corresponding to $\mathtt{evenp}$ (or $\mathtt{oddp}$ ). Such a predicate must check that a given function returns non-zero for all integers, but this is simply not computable.

1.2 Our Work

We develop a formal calculus PCFv $\Delta_{\mathrm{H}}$ , a manifest contract system with intersection types. The goal of this paper is to prove its desirable properties: preservation, progress, value inversion; and one that guarantees that the existence of dynamic checking does not change the “essence” of computation.

There are several tasks in constructing a manifest contract system, but a specific challenge for PCFv $\Delta_{\mathrm{H}}$ arises from the fact—manifest contract systems are intended as an intermediate language for hybrid type checking [10]. Firstly, consider the following definition with a parity contract in a surface language.

[TABLE]

Supposing the primitive operator $\mathtt{succ}(x)$ has the type $\mathtt{nat}\rightarrow\mathtt{nat}$ , we need to check subtyping relation $\mathtt{odd}<:\mathtt{nat}$ and $\mathtt{nat}<:\mathtt{even}$ to check well-typedness of the definition. As we have mentioned, however, this kind of subtyping checking is undecidable in general. So, (when the checking is impossible) we insert casts to check the contract at run-time and obtain the following compiled definition.

[TABLE]

A problem arises when we consider the following definition equipped with a more complicated parity contract.

[TABLE]

The problem is that we need to insert different casts into code according to how the code is typed; and one piece of code might be typed in several essentially different ways in an intersection type system since it is a polymorphic type system. For instance, in the example above, $\lambda x\mathord{:}\mathtt{odd}.(\mathtt{succ}((x:\mathtt{odd}\Rightarrow\mathtt{nat})):\mathtt{nat}\Rightarrow\mathtt{even})$ is obtained by cast insertion if the function is typed as $\mathtt{odd}\rightarrow\mathtt{even}$ ; while $\lambda x\mathord{:}\mathtt{even}.(\mathtt{succ}((x:\mathtt{even}\Rightarrow\mathtt{nat})):\mathtt{nat}\Rightarrow\mathtt{odd})$ is obtained when the body is typed as $\mathtt{even}\rightarrow\mathtt{odd}$ . However, the function must have both types to have the intersection type. It may seem sufficient to just cast the body itself, that is, $((\lambda x\mathord{:}\mathtt{nat}.\mathtt{succ}(x)):\mathtt{nat}\rightarrow\mathtt{nat}\Rightarrow(\mathtt{odd}\rightarrow\mathtt{even})\wedge(\mathtt{even}\rightarrow\mathtt{odd}))$ . However, this just shelves the problem: Intuitively, to check if the subject has the target intersection type, we need to check if the subject has both types in the conjunction. This brings us back to the same original question.

1.2.1 Contributions.

Our contributions are summarized as follows:

•

we design a manifest contracts calculus with refinement intersection types [27, 33], a restricted form of intersection types.

•

we formalize the calculus PCFv $\Delta_{\mathrm{H}}$ ; and

•

we state and prove type soundness, value inversion, and dynamic soundness.

The whole system including proofs is mechanized with Coq.333The Coq scripts are available through the following URL: https://www.fos.kuis.kyoto-u.ac.jp/~igarashi/papers/manifest-intersection.html. We use locally nameless representation and cofinite quantification [5] for the mechanization.

1.2.2 Disclaimer.

To concentrate on the PCFv $\Delta_{\mathrm{H}}$ -specific problems, we put the following restrictions for PCFv $\Delta_{\mathrm{H}}$ in this paper compared to a system one would imagine from the phrase “a manifest contract system with intersection types”.

•

PCFv $\Delta_{\mathrm{H}}$ does not support dependent function types. As we will see, PCFv $\Delta_{\mathrm{H}}$ uses nondeterminism for dynamic checking. The combination of dependent function types and nondeterminism poses a considerable challenge [19].

•

We use refinement intersection types rather than general ones. Roughly speaking, $\sigma\wedge\tau$ is a refinement intersection type if both $\sigma$ and $\tau$ refine the same type. So, for example, $(\mathtt{even}\rightarrow\mathtt{even})\wedge(\mathtt{odd}\rightarrow\mathtt{odd})$ is a refinement intersection types since types of both sides refine the same type $\mathtt{nat}\rightarrow\mathtt{nat}$ , while $(\mathtt{nat}\rightarrow\mathtt{nat})\wedge(\mathtt{float}\rightarrow\mathtt{float})$ is not.

2 Overview of Our Language: PCFv $\Delta_{\mathrm{H}}$

Our language PCFv $\Delta_{\mathrm{H}}$ is a call-by-value dialect of PCF [20], extended with intersection types (derived from the $\Delta$ -calculus [17]) and manifest contracts (derived from $\lambda_{\textrm{H}}$ [10, 12]). So, the baseline is that any valid PCF program is also a valid PCFv $\Delta_{\mathrm{H}}$ program; and a PCFv $\Delta_{\mathrm{H}}$ program should behave as the same way as (call-by-value) PCF. In other words, PCFv $\Delta_{\mathrm{H}}$ is a conservative extension of call-by-value PCF.

2.1 The $\Delta$ -calculus

To address the challenge discussed in Section 1, PCFv $\Delta_{\mathrm{H}}$ is strongly influenced by the $\Delta$ -calculus by Liquori and Stolze [17], an intersection type system à la Church. Their novel idea is a new form called strong pair, written $\langle M,N\rangle$ . It is a kind of pair and used as a constructor for expressions of intersection types. So, using the strong pair, for example, we can write an identity function having type $(\mathtt{even}\rightarrow\mathtt{even})\wedge(\mathtt{odd}\rightarrow\mathtt{odd})$ as follows.

[TABLE]

Unlike product types, however, $M$ and $N$ in a strong pair cannot be arbitrarily chosen. A strong pair requires that the essence of both expressions in a pair be the same. An essence $\mathopen{\wr}M\mathclose{\wr}$ of a typed expression $M$ is the untyped skeleton of $M$ . For instance, $\mathopen{\wr}\lambda x\mathord{:}\tau.x\mathclose{\wr}=\lambda x.x$ . So, the requirement justifies strong pairs as the introduction of intersection types: that is, computation represented by the two expressions is the same and so the system still follows a Curry-style intersection type system. Strong pairs just give a way to annotate expressions with a different type in a different context.

We adapt their idea into PCFv $\Delta_{\mathrm{H}}$ by letting an essence represent the contract-irrelevant part of an expression, rather than an untyped skeleton. For instance, the essence of $\lambda x\mathord{:}\mathtt{odd}.(\mathtt{succ}((x:\mathtt{odd}\Rightarrow\mathtt{nat})):\mathtt{nat}\Rightarrow\mathtt{even})$ is $\lambda x\mathord{:}\mathtt{nat}.\mathtt{succ}(x)$ (the erased contract-relevant parts are casts and predicates of refinement types). Now, we can (ideally automatically) compile the $succ^{\prime}$ definition in Section 1 into the following PCFv $\Delta_{\mathrm{H}}$ expression.

[TABLE]

This strong pair satisfies the condition, that is, both expressions have the same essence.

2.2 Cast Semantics for Intersection Types

Having introduced intersection types, we have to extend the semantics of casts so that they handle contracts written with intersection types. Following Keil and Thiemann [14], who studied intersection (and union) contract checking in the “latent” style [12] for an untyped language, we give the semantics of a cast to an intersection type by the following rule:

[TABLE]

The reduction rule should not be surprising: $V$ has to have both $\tau_{{\mathrm{1}}}$ and $\tau_{{\mathrm{2}}}$ and a strong pair introduces an intersection type $\tau_{{\mathrm{1}}}\wedge\tau_{{\mathrm{2}}}$ from $\tau_{{\mathrm{1}}}$ and $\tau_{{\mathrm{2}}}$ . For the original cast to succeed, both of the split casts have to succeed.

A basic strategy of a cast from an intersection type is expressed by the following two rules.

[TABLE]

The cast tests whether a nondeterministically chosen element in a (possibly nested) strong pair can be cast to $\tau$ .

One problem, however, arises when a function type is involved. Consider the following expression.

[TABLE]

where

[TABLE]

$V$ can be used as both $\mathtt{even}\rightarrow\mathtt{nat}$ and $\mathtt{odd}\rightarrow\mathtt{nat}$ . This means $V$ can handle arbitrary natural numbers. Thus, this cast should be valid and evaluation of the expression above should not fail. However, with the reduction rules presented above, evaluation results in blame in both branches: the choice is made before calling $\lambda f:\mathtt{nat}\rightarrow\mathtt{nat}.\cdots$ , the function being assigned into $f$ only can handle either $\mathtt{even}$ or $\mathtt{odd}$ , leading to failure at either $f\,1$ or $f\,0$ , respectively.

To solve the problem, we delay a cast into a function type even when the source type is an intersection type. In fact, $M_{\text{cast}}$ reduces to a wrapped value $V_{\text{cast}}$ below

[TABLE]

similarly to higher-order casts [8]. Then, the delayed cast fires when an actual argument is given:

[TABLE]

3 Formal Systems

In this section, we formally define two languages PCFv and PCFv $\Delta_{\mathrm{H}}$ , an extension of PCFv as sketched in the last section. PCFv is a call-by-value PCF. We only give operational semantics and omit its type system and a type soundness proof, because we are only interested in how its behavior is related to PCFv $\Delta_{\mathrm{H}}$ , the main language of this paper.

3.1 PCFv

The syntax of PCFv is shown in Figure 1. Metavariables $x$ , $y$ , $z$ , $f$ , and $g$ range over term variables ( $f$ and $g$ are intended for ones bound to functions); $\sigma$ and $\tau$ range over types; $L$ , $M$ , and $N$ range over expressions; $V$ ranges over values; and $\mathcal{E}$ ranges over evaluation frames. The definition is fairly standard, except for one point: instead of introducing a constant for the general fix-point operator, we introduce a form $\mu f\mathord{:}\sigma_{{\mathrm{1}}}\rightarrow\sigma_{{\mathrm{2}}}.\lambda x\mathord{:}\tau.M$ for recursive functions.

Definition 1 (Bound and free variables)

An occurrence of $x$ in $M$ of $\lambda x\mathord{:}\tau.M$ and $f$ in $M$ of $\mu f\mathord{:}\sigma_{{\mathrm{1}}}\rightarrow\sigma_{{\mathrm{2}}}.\lambda x\mathord{:}\tau.M$ is called bound. The set of free variables in $M$ is the variables of which there are free occurrence in $M$ . We denote the free variables by $\mathtt{fv}(M)$ .

Convention

We define $\alpha$ -equivalence in a standard manner and identify $\alpha$ -equivalent expressions.

Definition 2 (Substitution)

Substitution of $N$ for a free variable $x$ in $M$ , written $M[x\mapsto N]$ , is defined in a standard capture-avoiding manner.

Definition 3 (Context application)

Given an evaluation frame $\mathcal{E}$ and an expression $M$ , $\mathcal{E}[M]$ denotes the expression obtained by just replacing the hole $\Box$ in $\mathcal{E}$ with $M$ .

A small-step operational semantics of PCFv is inductively defined by the rules in Figure 2. Those rules consist of standard (call-by-value) PCF axiom schemes and one rule scheme (PCF-Ctx), which expresses the call-by-value evaluation strategy using the evaluation frames.

3.2 PCFv $\Delta_{\mathrm{H}}$

PCFv $\Delta_{\mathrm{H}}$ is an extension of PCFv. Through abuse of syntax, we use the metavariables of PCFv for PCFv $\Delta_{\mathrm{H}}$ , though we are dealing with the two different languages.

The syntax of PCFv $\Delta_{\mathrm{H}}$ is shown in Figure 3. We introduce some more metavariables: $I$ ranges over interface types, a subset of types; $B$ ranges over recursion bodies, a subset of expressions; $C$ ranges over commands; and $\Gamma$ ranges over typing contexts. Shaded parts show differences (extensions and modifications) from PCFv. Types are extended with intersection types and refinement types; the restriction that a well-formed intersection type is a refinement intersection type is enforced by the type system. The variable $x$ in $N$ of $\{x\mathord{:}\tau\mid N\}$ is bound. An interface type, which is a single function type or (possibly nested) intersection over function types, is used for the type annotation for a recursive function. Expressions are extended with ones for: strong pairs (namely, pair construction, left projection, and right projection); casts; and run-time expressions of the form $\langle\!\langle\dots\rangle\!\rangle$ that can occur at run time for dynamic checking and not in source code. Recursion bodies are (possibly nested strong pairs) of $\lambda$ -abstractions.

Run-time expressions deserve detailed explanation. A delayed check $\langle\!\langle V:\sigma\Rightarrow\tau_{{\mathrm{1}}}\rightarrow\tau_{{\mathrm{2}}}\rangle\!\rangle$ denotes a delayed cast into a function type, which is used in cases such as those discussed in Section 1 for instance. A waiting check $\langle\!\langle M\mathrel{?}\{x\mathord{:}\tau\mid N\}\rangle\!\rangle$ denotes a state waiting for the check $M$ against $N$ until $M$ is evaluated into a value. An active check $\langle\!\langle M\Longrightarrow V:\{x\mathord{:}\tau\mid N\}\rangle\!\rangle$ is a state running test $M$ to see if $V$ satisfies $N$ . The variable $x$ in $N$ of $\langle\!\langle M\mathrel{?}\{x\mathord{:}\tau\mid N\}\rangle\!\rangle$ and $\langle\!\langle M\Longrightarrow V:\{x\mathord{:}\tau\mid N\}\rangle\!\rangle$ is bound.

We do not include $\mathtt{blame}$ in expressions, although existing manifest contract systems usually include it among expressions. As a consequence, the evaluation relation for PCFv $\Delta_{\mathrm{H}}$ is defined between commands. This distinction will turn out to be convenient in stating correspondence between the semantics of PCFv $\Delta_{\mathrm{H}}$ and that of PCFv, which does not have $\mathtt{blame}$ .

Convention

We assume the index variable $i$ ranges over $\{1,2\}$ to save space.

Definition 4 (Terms)

We call the union of the sets of types and expressions as terms.

Notation

$M\preceq N$ denotes that $M$ * is a sub-expression of $N$ *.

Convention

We define $\alpha$ -equivalence in a standard manner and identify $\alpha$ -equivalent terms.

Convention

We often omit the empty environment. We abuse a comma for the concatenation of environments like $\Gamma_{{\mathrm{1}}},\Gamma_{{\mathrm{2}}}$ . We denote a singleton environment, an environment that contains only one variable binding, by $x\mathord{:}\tau$ .

Definition 5 (Free variables and substitution)

Free variables and substitution are defined similarly to PCFv; and we use the same notations. Note that since the types and expressions of PCFv $\Delta_{\mathrm{H}}$ are mutually recursively defined, the metaoperations are inductively defined for terms.

Definition 6 (Domain of typing context)

The domain of $\Gamma$ , written $\mathtt{dom}(\Gamma)$ , is defined by: $\mathtt{dom}(\emptyset)=\emptyset$ and $\mathtt{dom}(\Gamma,x\mathord{:}\tau)=\mathtt{dom}(\Gamma)\cup\{x\}$ . We abbreviate $x\mathrel{\not\in}\mathtt{dom}(\Gamma)$ to $x\mathrel{\#}\Gamma$ .

The essence of a PCFv $\Delta_{\mathrm{H}}$ term is defined in Figure 4, which is mostly straightforward. The choice of which part we take as the essence of a strong pair is arbitrary because for a well-typed expression both parts have the same essence. Note that the essence of an active check $\langle\!\langle M\Longrightarrow V:\{x\mathord{:}\tau\mid N\}\rangle\!\rangle$ is $V$ rather than $M$ . This is because $V$ is the subject of the expression.

3.3 Operational Semantics of PCFv $\Delta_{\mathrm{H}}$

The operational semantics of PCFv $\Delta_{\mathrm{H}}$ consists of four relations $M\rightharpoonup_{\textsf{p}}N$ , $M\rightharpoonup_{\textsf{c}}C$ , $M\longrightarrow_{\textsf{p}}N$ , and $M\longrightarrow_{\textsf{c}}C$ . Bearing in mind the inclusion relation among syntactic categories, these relations can be regarded as binary relations between commands. The first two are basic reduction relations, and the other two are contextual evaluation relations (relations for whole programs). Furthermore, the relations subscripted by p correspond to PCFv evaluation, that is, essential evaluation; and ones subscripted by c correspond to dynamic contract checking. Dynamic checking is nondeterministic because of (RC-WedgeL/R), (EC-PairL), and (EC-PairR).

3.3.1 Essential Evaluation $\longrightarrow_{\textsf{p}}$ .

The essential evaluation, defined in Figure 5, defines the evaluation of the essential part of a program; and thus, it is similar to $\longrightarrow_{\textsf{PCF}}$ . There are just three differences, that is: there are two relations; there is no reduction rule for $\mathtt{pred}(\mathtt{O})$ ; and there is a distinguished contextual evaluation rule (EP-PairS), which synchronizes essential reductions of the elements in a strong pair. The synchronization in (EP-PairS) is important since a strong pair requires the essences of both elements to be the same. The lack of predecessor evaluation for $\mathtt{O}$ is intentional: Our type system and run-time checking guarantee that $\mathtt{O}$ cannot occur as an argument to $\mathtt{pred}$ .

3.3.2 Dynamic Checking $\longrightarrow_{\textsf{c}}$ .

Dynamic checking is more complicated. Firstly, we focus on reduction rules in Figure 6. The side-conditions on some rules are set so that an evaluation is less nondeterministic (for example, without the side conditions, both (RC-Forget) and (RC-Delay) could be applied to one expression).

The rules irrelevant to intersection types ((RC-Nat), (RC-Bool), (RC-Forget), (RC-Delay), (RC-Arrow), (RC-Waiting), (RC-Activate), (RC-Succeed), and (RC-Fail)) are adopted from Sekiyama et al. [26], but there is one difference about (RC-Delay) and (RC-Arrow). In the original definition delayed checking is done by using lambda abstractions, that is,

[TABLE]

The reason we adopt a different way is just it makes technical development easier. Additionally, the way we adopt is not new—It is used in the original work [8] on higher-order contract calculi.

The other rules are new ones we propose for dynamic checking of intersection types. As we have discussed in Section 2, a cast into an intersection type is reduced into a pair of casts by (RC-WedgeI). A cast from an intersection type is done by (RC-Delay), (RC-WedgeL/R) if the target type is a function type. Otherwise, if the target type is a first order type, (RC-WedgeN) and (RC-WedgeB) are used, where we arbitrarily choose the left side of the intersection type and the corresponding part of the value since the source type is not used for dynamic checking of first-order values.

The contextual evaluation rules, defined in Figure 7, are rather straightforward. Be aware of the use of metavariables, for instance, the use of $N$ in (EC-Ctx); it implicitly means that $M$ has not been evaluated into $\mathtt{blame}$ (so the rule does not overlap with (EB-Ctx)). The first rule lifts the reduction relation to the evaluation relation. The next six rules express the case where a sub-expression is successfully evaluated. The rules (EC-ActiveP) and (EC-ActiveC) mean that evaluation inside an active check is always considered dynamic checking, even when it involves essential evaluation. The rules (EC-PairL) and (EC-PairR) mean that dynamic checking does not synchronize because the elements in a strong pair may have different casts. The other rules express the case where dynamic checking has failed. An expression evaluates to $\mathtt{blame}$ immediately—in one step—when a sub-expression evaluates to $\mathtt{blame}$ . Here is an example of execution of failing dynamic checking.

[TABLE]

Definition 7 (Evaluation)

The one-step evaluation relation of PCFv $\Delta_{\mathrm{H}}$ , denoted by $\longrightarrow$ , is defined as $\longrightarrow_{\textsf{p}}\cup\longrightarrow_{\textsf{c}}$ . The multi-step evaluation relation of PCFv $\Delta_{\mathrm{H}}$ , denoted by $\longrightarrow^{\ast}$ , is the reflexive and transitive closure of $\longrightarrow$ .

3.4 Type System of PCFv $\Delta_{\mathrm{H}}$

The type system consists of three judgments: $\Gamma\;\mathrm{ok}$ , $\Vdash\tau$ , and $\Gamma\vdash M:\tau$ , read “ $\Gamma$ is well-formed”, “ $\tau$ is well-formed”, and “ $M$ has $\tau$ under $\Gamma$ ,” respectively. They are defined inductively by the rules in Figures 8, 9 and 10.

The rules for well-formed types check that an intersection type is restricted to a refinement intersection type by the side condition $\mathopen{\wr}\sigma\mathclose{\wr}=\mathopen{\wr}\tau\mathclose{\wr}$ in (W-Wedge) and that the predicate in a refinement type is a Boolean expression by (W-Refine). Note that, since PCFv $\Delta_{\mathrm{H}}$ has no dependent function type, all types are closed and the predicate of a refinement type only depends on the parameter itself.

The typing rules, the rules for the third judgment, consist of two more sub-categories: compile-time rules and run-time rules. Compile-time rules are for checking a program a programmer writes. Run-time rules are for run-time expressions and used to prove type soundness. This distinction, which follows, Belo et al. [1], is to make compile-time type checking decidable.

A large part of the compile-time rules are adapted from PCF, Sekiyama et al. [26], and Liquori and Stolze [17]. Here we explain some notable rules. As an intersection type system, (T-Pair), (T-Fst), and (T-Snd) stands for introduction and elimination rules of intersection types (or we can explicitly introduce and/or eliminate an intersection type by a cast). The rule (T-Pair) checks a strong pair is composed by essentially the same expressions by $\mathopen{\wr}M\mathclose{\wr}=\mathopen{\wr}N\mathclose{\wr}$ . The rule (T-Pred) demands that the argument of predecessor shall not be zero. The premise $\mathopen{\wr}\sigma\mathclose{\wr}=\mathopen{\wr}\tau\mathclose{\wr}$ of the rule (T-Cast) for casts requires the essences of the source and target types to agree. It amounts to checking the two types $\sigma$ and $\tau$ are compatible [26].

The run-time rules are from Sekiyama et al. [26] with one extra rule (T-Delayed). The rule (T-Delayed) is for a delayed checking for function types, which restrict the source type so that it respects the evaluation relation (there is no evaluation rule for a delayed checking in which source type is a refinement type), and inherits the condition on the source and target types from (T-Cast). The side condition $N[x\mapsto V]\longrightarrow^{\ast}M$ on (T-Active) is an invariant during evaluation, that is, $M$ is an intermediate state of the predicate checking. This invariant lasts until the final (successful) run-time checking state $\langle\!\langle\mathtt{true}\Longrightarrow V:\{x\mathord{:}\tau\mid N\}\rangle\!\rangle$ and guarantees the checking result $V$ (obtained by (RC-Succeed)) satisfies the predicate $N$ by (T-Exact).

4 Properties

We start from properties of evaluation relations. As we have mentioned, $\longrightarrow_{\textsf{p}}$ is essential evaluation, and thus, it should simulate $\longrightarrow_{\textsf{PCF}}$ ; and $\longrightarrow_{\textsf{c}}$ is dynamic checking, and therefore, it should not change the essence of the expression. We formally state and show these properties here. Note that most properties require that the expression before evaluation is well typed. This is because the condition of strong pairs is imposed by the type system.

Lemma 1

If $M\longrightarrow_{\textsf{PCF}}N$ and $M\longrightarrow_{\textsf{PCF}}L$ , then $N=L$ .

Proof

The proof is routine by induction on one of the given derivations. ∎

Lemma 2

If $\vdash M:\tau$ and $M\longrightarrow_{\textsf{p}}N$ , then $\mathopen{\wr}M\mathclose{\wr}\longrightarrow_{\textsf{PCF}}\mathopen{\wr}N\mathclose{\wr}$ .

Proof

The proof is by induction on the given evaluation derivation. ∎

The following corollary is required to prove the preservation property.

Corollary 1

If $\vdash M:\sigma$ , $\vdash N:\tau$ , $M\longrightarrow_{\textsf{p}}M^{\prime}$ , $N\longrightarrow_{\textsf{p}}N^{\prime}$ , and $\mathopen{\wr}M\mathclose{\wr}=\mathopen{\wr}N\mathclose{\wr}$ ; then $\mathopen{\wr}M^{\prime}\mathclose{\wr}=\mathopen{\wr}N^{\prime}\mathclose{\wr}$ .

Lemma 3

If $\vdash M:\tau$ and $M\longrightarrow_{\textsf{c}}N$ , then $\mathopen{\wr}M\mathclose{\wr}=\mathopen{\wr}N\mathclose{\wr}$ .

Proof

The proof is by induction on the given evaluation derivation. ∎

Now we can have the following theorem as a corollary of 2 and 3. It guarantees the essential computation in PCFv $\Delta_{\mathrm{H}}$ is the same as the PCFv computation as far as the computation does not fail. In other words, run-time checking may introduce blame but otherwise does not affect the essential computation.

Theorem 4.1

If $\vdash M:\tau$ and $M\longrightarrow N$ , then $\mathopen{\wr}M\mathclose{\wr}\longrightarrow_{\textsf{PCF}}^{\ast}\mathopen{\wr}N\mathclose{\wr}$ .

4.1 Type Soundness

We conclude this section with type soundness. Firstly, we show a substitution property; and using it, we show the preservation property.

Lemma 4

If $\Gamma_{{\mathrm{1}}},x\mathord{:}\sigma,\Gamma_{{\mathrm{2}}}\vdash M:\tau$ and $\Gamma_{{\mathrm{1}}}\vdash N:\sigma$ , then $\Gamma_{{\mathrm{1}}},\Gamma_{{\mathrm{2}}}\vdash M[x\mapsto N]:\tau$ .

Proof

The proof is by induction on the derivation for $M$ . ∎

Theorem 4.2 (Preservation)

If $\vdash M:\tau$ and $M\longrightarrow N$ , then $\vdash N:\tau$ .

Proof

We prove preservation properties for each $\longrightarrow_{\textsf{p}}$ and $\longrightarrow_{\textsf{c}}$ and combine them. Both proofs are done by induction on the given typing derivation. For the case in which substitution happens, we use 4 as usual. For the context evaluation for strong pairs, we use 1 and 3 to guarantee the side-condition of strong pairs. ∎

Next we show the value inversion property, which guarantees a value of a refinement type satisfies its predicate. For PCFv $\Delta_{\mathrm{H}}$ , this property can be quite easily shown since PCFv $\Delta_{\mathrm{H}}$ does not have dependent function types, while previous manifest contract systems need quite complicated reasoning [26, 24, 19]. The property itself is proven by using the following two, which are for strengthening an induction hypothesis.

Definition 8

We define a relation between values and types, written $V\models\tau$ , by the following rules.

$V\models\tau$ $M[x\mapsto V]\longrightarrow^{\ast}\mathtt{true}$

$V\models\{x\mathord{:}\tau\mid M\}$

$(\tau\neq\{x\mathord{:}\sigma\mid M\})$

$V\models\tau$

Lemma 5

If $\vdash V:\tau$ , then $V\models\tau$ .

Proof

The proof is by induction on the given derivation. ∎

Theorem 4.3 (Value inversion)

If $\vdash V:\{x\mathord{:}\tau\mid M\}$ , then $M[x\mapsto V]\longrightarrow^{\ast}\mathtt{true}$ .

Proof

Immediate from 5. ∎

Remark 1

As a corollary of value inversion, it follows that a value of an intersection type must be a strong pair and its elements satisfy the corresponding predicate in the intersection type: For example, if $\vdash\langle V_{{\mathrm{1}}},V_{{\mathrm{2}}}\rangle:\{x\mathord{:}\sigma\mid M\}\wedge\{x\mathord{:}\tau\mid N\}$ , then $M[x\mapsto V_{{\mathrm{1}}}]\longrightarrow^{\ast}\mathtt{true}$ and $N[x\mapsto V_{{\mathrm{2}}}]\longrightarrow^{\ast}\mathtt{true}$ . In particular, for first-order values, every element of the pair is same. That means the value satisfies all contracts concatenated by $\wedge$ . For example, $\vdash V:\{x\mathord{:}\mathtt{nat}\mid M_{{\mathrm{1}}}\}\wedge\dots\wedge\{x\mathord{:}\mathtt{nat}\mid M_{n}\}$ , then $M_{k}[x\mapsto\mathopen{\wr}V\mathclose{\wr}]\longrightarrow^{\ast}\mathtt{true}$ for any $k=1..n$ . This is what we have desired for a contract written by using intersection types.

Lastly, the progress property also holds. In our setting, where $\mathtt{pred}(M)$ is partial, this theorem can be proved only after Theorem 4.3.

Theorem 4.4 (Progress)

If $\vdash M:\tau$ , then $M$ is a value or $M\longrightarrow C$ for some $C$ .

Proof

The proof is by induction on the given derivation. Since the evaluation relation is defined as combination of $\longrightarrow_{\textsf{p}}$ and $\longrightarrow_{\textsf{c}}$ , the proof is a bit tricky, but most cases can be proven as usual. An interesting case is (T-Pair). We need to guarantee that if one side of a strong pair is a value, another side must not be evaluated by $\longrightarrow_{\textsf{p}}$ since a value is in normal form. This follows from 2 and proof by contradiction because the essence of a PCFv $\Delta_{\mathrm{H}}$ value is a PCFv value and it is normal form. ∎

5 Related Work

Intersection types were introduced in Curry-style type assignment systems by Coppo et al. [6] and Pottinger [21] independently. In the early days, intersection types are motivated by improving a type system to make more lambda terms typeable; one important result towards this direction is that: a lambda term has a type iff it can be strongly normalized [21, 29]. Then, intersection types are introduced to programming languages to enrich the descriptive power of types [22, 2, 7].

5.0.1 Intersection Contracts for Untyped Languages.

One of the first attempts at implementing intersection-like contracts is found in DrRacket [9]. It is, however, a naive implementation, which just enforces all contracts even for functional values, and thus the semantics of higher-order intersection contracts is rather different from ours.

Keil and Thiemann [14] have proposed an untyped calculus of blame assignment for a higher-order contract system with intersection and union. As we have mentioned, our run-time checking semantics is strongly influenced by their work, but there are two essential differences. On the one hand, they do not have the problem of varying run-time checking according to a typing context; they can freely put contract monitors444A kind of casts in their language. where they want since it is an untyped language. On the other hand, their operational semantics is made rather complicated due to blame assignment.

More recently, Williams et al. [32] have proposed more sorted out semantics for a higher-order contract system with intersection and union. They have mainly reformed contract checking for intersection and union “in a uniform way”; that is, each is handled by only one similar and simpler rule. As a result, their presentation becomes closer to our semantics, though complication due to blame assignment still remains. A similar level of complication will be expected if we extend our calculus with blame assignment.

It would be interesting to investigate the relationship between their calculi and PCFv $\Delta_{\mathrm{H}}$ extended with blame labels, following Greenberg et al. [12].

5.0.2 Gradual Typing with Intersection Types.

Castagna and Lanvin [3] have proposed gradual typing for set-theoretic types, which contain intersection types, as well as union and negation. A framework of gradual typing is so close to manifest contract systems that there is even a study unifying them [31]. A gradual typing system translates a program into an intermediate language that is statically typed and uses casts. Hence, they have the same problem—how casts should be inserted when intersection types are used. They solve the problem by type-case expressions, which dynamically dispatch behavior according to the type of a value. However, it is not clear how type-case expressions scale to a larger language. In fact, the following work [4], an extension to parametric polymorphism and type inference, removes (necessity of) type-case expressions but imposes instead a restriction on functions not to have an intersection type. Furthermore, the solution using type-case expressions relies on strong properties of set-theoretic types. So, it is an open problem if their solution can be adopted to manifest contract systems because there is not set-theoretic type theory for refinement types and, even worse, dependent function types.

5.0.3 Nondeterminism for Dependently Typed Languages.

As we have noted in Section 1, PCFv $\Delta_{\mathrm{H}}$ has no dependent function types. In fact, no other work discussed in this section supports both dependent function contracts and intersection contracts. To extend PCFv $\Delta_{\mathrm{H}}$ to dependent function types, we have to take care of their interaction with nondeterminism, which we studied elsewhere [19] for a manifest calculus $\lambda^{H\parallel\Phi}$ with a general nondeterministic choice operator.

A technical challenge in combining dependent function types and nondeterminstic choice comes from the following standard typing rule for (dependent) function applications:

$\Gamma\vdash M:(x\mathord{:}\sigma)\rightarrow\tau$ $\Gamma\vdash N:\sigma$

$\Gamma\vdash M\,N:\tau[x\mapsto N]$

The problem is that the argument $N$ , which may contain nondeterministic choice, may be duplicated in $\tau[x\mapsto N]$ and, to keep consistency of type equivalence, choices made in each occurrence of $N$ have to be “synchronized.” To control synchronization, $\lambda^{H\parallel\Phi}$ introduces a named choice operator so that choice operators with the same name make synchronized choice. However, $\lambda^{H\parallel\Phi}$ puts burden on programmers to avoid unintended synchronization caused by accidentally shared names.

If we incoporate the idea above to PCFv $\Delta_{\mathrm{H}}$ , it will be natural to put names on casts so that necessary synchronization takes place for choices made by (RC-WedgeL) and (RC-WedgeR). It is not clear, however, how unintended synchronization can be avoided systematically, without programmers’ ingenuity.

6 Conclusion

We have designed and formalized a manifest contract system PCFv $\Delta_{\mathrm{H}}$ with refinement intersection types. As a result of our formal development, PCFv $\Delta_{\mathrm{H}}$ guarantees not only ordinary preservation and progress but also the property that a value of an intersection type, which can be seen as an enumeration of small contracts, satisfies all the contracts.

The characteristic point of our formalization is that we regard a manifest contract system as an extension of a more basic calculus, which has no software contract system, and investigate the relationship between the basic calculus and the manifest contract system. More specifically, essential computation and dynamic checking are separated. We believe this investigation is important for modern manifest contract systems because those become more and more complicated and the separation is no longer admissible at a glance.

6.0.1 Future Work.

Obvious future work is to lift the restriction we have mentioned in Section 1. That aside, the subsumption-free approach is very naive and has an obvious disadvantage, that is, it requires run-time checking even for a cast like $(M:\sigma\wedge\tau\Rightarrow\sigma)$ , which should be able to checked and removed at compile time. To address the disadvantage, some manifest contract systems provide the property known as up-cast elimination [1]—a cast from subtype into supertype can be safely removed at compile-time. An interesting fact is that a well-known up-cast (subtyping) relation for a traditional intersection type system is defined syntactically; while a usual up-cast relation for a manifest contract system depends on semantics. So, focusing on only the traditional subtyping relation, the property might be proven more easily.

Towards a practice language, our cast semantics using strong pairs and nondeterminism needs more investigation. For the strong pairs, it will be quite inefficient to evaluate both sides of a strong pair independently since its essence part just computes the same thing. The inefficiency might be reduced by a kind of sharing structures. For the nondeterminism, our theoretical result gives us useful information only for successful evaluation paths; but we have not given a way to pick up a successful one. One obvious way is computing every evaluation path, but of course, it is quite inefficient.

Acknowledgments

We would like to thank Peter Thiemann, John Toman, Yuya Tsuda, and anonymous reviewers for useful comments. This work was supported in part by the JSPS KAKENHI Grant Number JP17H01723.

Bibliography33

The reference list from the paper itself. Each links out to its DOI / PubMed record.

1[1] Belo, J.F., Greenberg, M., Igarashi, A., Pierce, B.C.: Polymorphic contracts. In: Proc. of ESOP. pp. 18–37 (2011)
2[2] Benzaken, V., Castagna, G., Frisch, A.: C Duce: an XML-centric general-purpose language. In: Proc. of ICFP. pp. 51–63 (2003)
3[3] Castagna, G., Lanvin, V.: Gradual typing with union and intersection types. PACMPL 1 (ICFP), 41:1–41:28 (2017)
4[4] Castagna, G., Lanvin, V., Petrucciani, T., Siek, J.G.: Gradual typing: A new perspective. Proc. ACM Program. Lang. 3 (POPL), 16:1–16:32 (Jan 2019)
5[5] Charguéraud, A.: The locally nameless representation. J. Autom. Reasoning 49 (3), 363–408 (2012)
6[6] Coppo, M., Dezani-Ciancaglini, M., Venneri, B.: Functional characters of solvable terms. Math. Log. Q. 27 (2-6), 45–58 (1981)
7[7] Dunfield, J.: Refined typechecking with Stardust. In: Proc. of PLPV. pp. 21–32 (2007)
8[8] Findler, R.B., Felleisen, M.: Contracts for higher-order functions. In: Proc. of ICFP. pp. 48–59 (2002)

TL;DR

Contribution

Findings

Abstract

Peer Reviews

Videos

Taxonomy

Manifest Contracts with Intersection Types

Abstract

1 Introduction

1.1 Motivation

1.2 Our Work

1.2.1 Contributions.

1.2.2 Disclaimer.

2 Overview of Our Language: PCFvΔH\Delta_{\mathrm{H}}ΔH​

2.1 The Δ\DeltaΔ-calculus

2.2 Cast Semantics for Intersection Types

3 Formal Systems

3.1 PCFv

Definition 1 (Bound and free variables)

Convention

Definition 2 (Substitution)

Definition 3 (Context application)

3.2 PCFvΔH\Delta_{\mathrm{H}}ΔH​

Convention

Definition 4 (Terms)

Notation

Convention

Convention

Definition 5 (Free variables and substitution)

Definition 6 (Domain of typing context)

3.3 Operational Semantics of PCFvΔH\Delta_{\mathrm{H}}ΔH​

3.3.1 Essential Evaluation ⟶p\longrightarrow_{\textsf{p}}⟶p​.

3.3.2 Dynamic Checking ⟶c\longrightarrow_{\textsf{c}}⟶c​.

Definition 7 (Evaluation)

3.4 Type System of PCFvΔH\Delta_{\mathrm{H}}ΔH​

4 Properties

Lemma 1

Proof

Lemma 2

Proof

Corollary 1

Lemma 3

Proof

Theorem 4.1

4.1 Type Soundness

Lemma 4

Proof

Theorem 4.2 (Preservation)

Proof

Definition 8

Lemma 5

Proof

Theorem 4.3 (Value inversion)

Proof

Remark 1

Theorem 4.4 (Progress)

Proof

5 Related Work

5.0.1 Intersection Contracts for Untyped Languages.

5.0.2 Gradual Typing with Intersection Types.

5.0.3 Nondeterminism for Dependently Typed Languages.

6 Conclusion

6.0.1 Future Work.

Acknowledgments

2 Overview of Our Language: PCFv $\Delta_{\mathrm{H}}$

2.1 The $\Delta$ -calculus

3.2 PCFv $\Delta_{\mathrm{H}}$

3.3 Operational Semantics of PCFv $\Delta_{\mathrm{H}}$

3.3.1 Essential Evaluation $\longrightarrow_{\textsf{p}}$ .

3.3.2 Dynamic Checking $\longrightarrow_{\textsf{c}}$ .

3.4 Type System of PCFv $\Delta_{\mathrm{H}}$