Affine Contracts for Affine Types Jesse A. Tov Riccardo Pucella Northeastern University ftov,[email protected] Abstract ML-like language illustrates why conventional type systems are Affine and other substructural type systems offer a range of expres- inadequate to the task of typing strong updates: siveness and performance benefits but cannot easily interact with fun tricky (r1: (int ! int) ref, r2: (int ! int) ref): int = components written in non-affine languages in a safe manner. We let val f = !r1 propose a technique for regulating the interaction between code val = r1 := 0 written in an affine language and code written in a conventional val g = !r2 typed language by means of contracts. in f (g 2) end We formalize our approach via a typed calculus with both affine-typed and conventionally typed modules. An affine type If we invoke tricky(r, r), where r is a reference cell containing an system is used for affine modules and a conventional type system int ! int function, then g in the code above will be an integer rather for conventional modules, and neither type system is aware of the than a function, resulting in a run-time fault. The problem occurs other. We show how to preserve the properties guaranteed by the only if the two arguments to tricky are aliases for the same reference two type systems despite modules being able to call each other and cell, which a linear or affine type system can prevent. exchange values arbitrarily, and we establish the correctness of our Beyond strong updates, substructural types have been used approach through a syntactic type soundness theorem. for memory management (Jim et al. 2002), for optimization of lazy languages (Turner et al. 1995), and to handle effects in pure Categories and Subject Descriptors D.2.4 [Software Engineer- languages (Barendsen and Smetsers 1996). Typestate (Strom and ing]: Software/Program Verification—Programming by contract; Yemini 1986) and session types (Gay and Hole 1999) can also be F.4.1 [Mathematical Logic and Formal Languages]: Mathematical understood as substructural type systems, although they are not Logic—Affine Logic always presented as such. Given the range of language features that substructural types can General Terms Languages, Reliability express, a programmer may wish to take advantage of these features in writing real-world programs. Writing real systems, however, Keywords Contracts, affine types, substructural logic, multi- often requires access to comprehensive libraries, which mainstream language systems programming languages generally provide but prototype imple- mentations often do not. The prospect of rewriting libraries to work 1. Introduction in a substructural language strikes these authors as unappealing. This suggests allowing conventional and substructural lan- Substructural type systems augment conventional type systems guages to interoperate. We envision the following scenarios: with the ability to control the number and order of uses of a data structure or operation (Walker 2005). The most common • The programmer wishes to import a legacy library into a sub- substructural type systems are linear type systems (Wadler 1990; structural language. Unfortunately, if the library is unaware Plotkin 1993; Benton 1995; Ahmed et al. 2004). Roughly speaking, of the substructural conditions then it may duplicate values a linear type system ensures that values with linear type cannot received from the substructural language. be duplicated or dropped: a value of linear type must be elimi- • The programmer wishes to write a library in a substructural nated exactly once. Other substructural type systems refine these language but provide access to the library from a conventional constraints. Affine type systems, for instance, enforce that values language. The naive client may duplicate values it receives cannot be duplicated, but allow them to be dropped: a value of from a substructural library and resubmit them, causing aliasing affine type may be used once or not at all. that the substructural library could not produce by itself and A common use case for substructural type systems is to type bypassing the guarantees of the substructural type system. check reference cells that support strong updates, that is, where the type of a value stored in a cell can be different at different points Our Contributions. The core contribution of this paper is a novel during the execution of a program. The following example in an approach to regulating the interaction between an affine language and a conventionally typed language. We present a calculus having several notable features: • The non-affine language may gain access to affine values, in- cluding strongly-updatable references, and may apply affine- language functions. • The non-affine type system has no awareness of the affine type system. [Copyright notice will appear here once ’preprint’ option is removed.] • And yet, the resulting system enjoys type soundness. 1 2009/3/2 We expect our technique to be efficiently implementable on real variables x; y hardware. module names f; g Our calculus consists of two sublanguages with different type integers z systems: a simply-typed λ calculus with a completely standard type system and a λ calculus with an affine type system. We have chosen programs P ::= M e declarations M ::= • j M m an affine rather than linear type system because what it means for u an affine invariant to be violated is significantly clearer than what it modules m ::= module f : σ = v means for a linear invariant to be violated. (We revisit this point in expressions e ::= v j x j f j e e j if0 e e e x6.) Our affine language provides strong updates as a simple stand- j he; ei j let hx; xi = e in e in for the variety of features such as typestate that they subsume. values v ::= λx:σ:e j c j hv; vi A program is a collection of modules and a main expression, constants c ::= dze j new j swap j · · · and each module may be written in either of the two sublanguages. a u types σ ::= σ j σ Modules in each language have access to modules written in the u u unlimited types σu ::= int j σ 1 σ j σ ⊗ σ other language, though they view foreign types through a transla- ( a a affine types σa ::= σ ref j σ 1 σ j σ ⊗ σ j σ ⊗ σ tion into the native type system. Affine modules are checked by ( arrows ∗ ::= 1 j 1 an affine type system, and non-affine modules are checked by the ( ( ( conventional type system. Notably, the conventional type system has no knowledge of affine types and their properties. Figure 1. A syntax To allow modules to invoke each other and exchange values while preserving the safety properties guaranteed by the individual type systems, we need to perform runtime checks in cases where affine sublanguage in x3. In x4 we introduce our multi-language the non-affine type system is too weak to express the affine type calculus and attempt to justify some of its design. The impatient system’s invariants for values that flow between the languages. reader may wish to skip to x4.3 on page 7 for examples. We explain For instance, the affine type system guarantees that an affine value our soundness criterion, state a standard type soundness theorem, created in an affine module will not be duplicated within the affine and discuss highlights of the proof in x5. We explore alternate sublanguage. If the value flows into a non-affine module, however, design ideas, extensions, and future research possibilities in x6 and static bets are off. In that case, we resort to a dynamic check that conclude in x7. prevents the value from flowing back into an affine context—where To distinguish the two languages of our calculus, we typeset our it can be used—more than once. Since our calculus is higher-order, affine language A in a sans-serif font and our non-affine language we use a form of higher-order contract (Findler and Felleisen 2002) C in a bold serif font. to keep track of each module’s obligations toward maintaining the affine invariants. 2. The Affine Sublanguage In Findler and Felleisen’s formulation, a software contract is A an agreement between two software components, or parties, about We begin with our affine sublanguage, which we call A (for some property of a value. The positive party produces a value, “affine,” typeset in sans-serif). Figure 1 presents the syntax of types which must satisfy the specified property. The negative party con- and terms. sumes the value and is held responsible to treat it appropriately. In preparation for adding contracts, A includes modules, which Contracts are concerned with catching violations of the property act as contractual parties. For simplicity, a module declares only and blaming the guilty party, which may help locate the source of a one name bound to one value. A program comprises a mutually bug. For first-order values, the contract may be immediately check- recursive collection of modules M and a main expression e. able, but for functional values, the property is likely undecidable, Expressions are mostly conventional: values, which include λ so the check must wait until the negative party applies the function, expressions, several constants, pairs of values, and dze for integer at which point the negative party is responsible for providing a literals; variables; application; if expressions; pair construction; suitable argument and the positive party for producing a suitable and pair elimination. Less conventionally, expressions also include result. Thus, for higher-order functions, checks are delayed until module names (f), which reduce to the value of the named module. first-order values are reached. We define the free variables of an expression in the usual way, but Our approach to integrating affine and conventional types note that this includes only regular variables (e.g., y), not module borrows heavily from recent literature on multi-language inter- names (e.g., g), which we assume are distinguished syntactically.