Types and Trace Effects of Higher Order...

68
Types and Trace Effects of Higher Order Programs Christian Skalka 1 , Scott Smith 2 , and David Van Horn 3 1 The University of Vermont [email protected] 2 The Johns Hopkins University, [email protected] 3 Brandeis University [email protected] Abstract. This paper shows how type effect systems can be combined with model-checking techniques to produce powerful, automatically verifiable pro- gram logics for higher order programs. The properties verified are based on the ordered sequence of events that occur during program execution, so called event traces. Our type and effect systems infer conservative approximations of the event traces arising at run-time, and model-checking techniques are used to verify log- ical properties of these histories. Our language model is based on the λ-calculus. Technical results include a type inference algorithm for a polymorphic type ef- fect system, and a method for applying known model-checking techniques to the trace effects inferred by the type inference algorithm, allowing static enforcement of history- and stack-based security mechanisms. A type safety result is proven for both unification and subtyping constraint versions of the type system, ensur- ing that statically well-typed programs do not contain trace event checks that can fail at run-time. 1 Introduction Safe and secure program execution is crucial for modern information systems, but is difficult to attain in practice due to both programmer errors and intentional attacks. Various programming language-based techniques exist for increasing program safety, by verifying at compile- and/or run-time that programs possess certain safety proper- ties. In addition to narrowly focused systems for verification of specific properties such as memory safety or stack inspection security, recent research has explored security paradigms for enforcing general classes of properties. One such paradigm comprises the class of properties of program event traces that can be expressed in temporal log- ics [35, 32, 23, 5, 20]. This paper establishes a foundation for automated verification of higher order programs in this paradigm, using type and effect analysis. We develop a process for automatically predicting program event traces at compile-time and for stat- ically verifying properties of traces. Events are records of program actions, explicitly inserted into program code either manually (by the programmer) or automatically (by the compiler). Events are suffi- ciently abstract to represent a variety of program actions—e.g. opening a file, access control privilege activation, or entry to or exit from critical regions. Event traces main- tain the ordered sequences of events that occur during program execution, and assertions enforce properties of event traces.While such properties can be anything in the abstract, in practice they must be expressed in automatically verifiable logics. Therefore, we use model-checkable linear temporal logics that express regular properties of traces [37].

Transcript of Types and Trace Effects of Higher Order...

Page 1: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs

Christian Skalka1, Scott Smith2, and David Van Horn3

1 The University of [email protected] The Johns Hopkins University,[email protected] Brandeis [email protected]

Abstract. This paper shows how type effect systems can be combined withmodel-checking techniques to produce powerful, automatically verifiable pro-gram logics for higher order programs. The properties verified are based on theordered sequence of events that occur during program execution, so calledeventtraces. Our type and effect systems infer conservative approximations of the eventtraces arising at run-time, and model-checking techniques are used to verify log-ical properties of these histories. Our language model is based on theλ-calculus.Technical results include a type inference algorithm for a polymorphic type ef-fect system, and a method for applying known model-checking techniques to thetrace effectsinferred by the type inference algorithm, allowing static enforcementof history- and stack-based security mechanisms. A type safety result is provenfor both unification and subtyping constraint versions of the type system, ensur-ing that statically well-typed programs do not contain trace event checks that canfail at run-time.

1 Introduction

Safe and secure program execution is crucial for modern information systems, but isdifficult to attain in practice due to both programmer errors and intentional attacks.Various programming language-based techniques exist for increasing program safety,by verifying at compile- and/or run-time that programs possess certain safety proper-ties. In addition to narrowly focused systems for verification of specific properties suchas memory safety or stack inspection security, recent research has explored securityparadigms for enforcing general classes of properties. One such paradigm comprisesthe class of properties of programevent tracesthat can be expressed in temporal log-ics [35, 32, 23, 5, 20]. This paper establishes a foundation for automated verification ofhigher order programs in this paradigm, using type and effect analysis. We develop aprocess for automatically predicting program event traces at compile-time and for stat-ically verifying properties of traces.

Events are records of program actions, explicitly inserted into program code eithermanually (by the programmer) or automatically (by the compiler). Events are suffi-ciently abstract to represent a variety of program actions—e.g. opening a file, accesscontrol privilege activation, or entry to or exit from critical regions. Event traces main-tain the ordered sequences of events that occur during program execution, and assertionsenforce properties of event traces.While such properties can be anything in the abstract,in practice they must be expressed in automatically verifiable logics. Therefore, we usemodel-checkable linear temporal logics that express regular properties of traces [37].

Page 2: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

2 Christian Skalka, Scott Smith, and David Van Horn

For example, if a program is sending and receiving data over an SSL socket, therelevant events are opening and closing of sockets, and reading and writing of datapackets. An example event trace produced by a program run could be:

ssl_open("snork.cs.jhu.edu",4434); ssl_hs_begin(4434);ssl_hs_success(4434); ssl_put(4434); ssl_get(4434);ssl_open("moo.cs.uvm.edu",4435); ssl_hs_begin(4434);ssl_put(4435); ssl_close(4434); ssl_close(4435)

Here,ssl_open is a sample event with two arguments, a url and a port. Event tracescan then be used to detect logical flaws or security violations. For SSL, sockets mustfirst be opened, handshake begun, handshake success, and only then can data be get/putover the socket. Thus, the above trace is illegal because data is put on socket 4435 beforenotification has been received that handshake was successful on that socket. Codifyingthis property of event traces as a local check in a decidable logic provides a rigorousdefinition of well-formedness,andallows mechanical verification of it.

Trace based analyses have been shown capable of statically enforcing flow-sensitivesecurity properties such as safe locking behavior [18] and resource usage policies suchas file usage protocols and memory management [23, 20]. In [4], an analysis adaptedfrom the one presented in this paper is used to enforce secure service composition. Thehistory-based access control model of [1] can be implemented with event traces andchecks [35], as can be the policies realizable in that model, e.g. sophisticated ChineseWall policies [1]. Stack-based security policies are also amenable to this form of anal-ysis, as shown in [35, 36] and this paper. In short, the combination of a primitive notionof program events with a temporal program logic for asserting properties of event tracesyields a powerful and general tool for enforcing program properties.

1.1 A Type-Based Approach

The focus of this paper is on the compile-time verification of higher order programtrace properties expressible in linear temporal logic. The verification itself is based onknown model checking techniques for program abstractions, and we define a novel typetheory to infer program trace abstractions, yielding a fully automated analysis. Theseabstractions, calledtrace effects, are integrated directly into the type language, so thattype reconstruction automates abstract interpretation of program trace behavior. We de-velop both aHindley-Milner (HM) stylesystem where types are represented in termform and the implementation relies on unification, and asubtyping constraintsystemwhere the implementation relies on constraint closure. The flexibility of parametricpolymorphism over types and effects is available in both systems. Type theory providesan especially rigorous and extensible foundation for the static analysis of trace-basedprogram properties in a higher order language setting. The main contribution of thispaper is the development and study of this foundation, and definition of a sound auto-mated system covering both automatic extraction of program trace approximations andtheir verification.

To characterize the analysis and prove its correctness, the metatheory of types pro-vides an appealing formalism. We demonstrate subject reduction, progress, and typesafety results for constraint subtyping, which extend to the Hindley-Milner system byvirtue of conservation of the latter in the former. Conservativity of both systems with

Page 3: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 3

respect to the underlying pure Hindley-Milner system is also demonstrated. Sound-ness and completeness of subtyping constraint inference is proved, as is soundness forunification-based inference. Completeness of constraint subtyping also entails a princi-pal types result for the system. So-calledtrace approximationis demonstrated for bothtype systems, meaning that trace effects conservatively approximate run-time trace be-havior.

To complete the analysis, we define and prove correct an automatic verificationtechnique for trace effects, based on model checking in the linearµ-calculus. We alsodevelop a variation on the language model, so that stack-based trace policies can bedefined. In a stack-based model, trace events are “popped” with their associated ac-tivations, allowing definition of policies such as stack inspection. The static analysisand type safety result is modified to accommodate this variation, requiring only a post-processing transformation of inferred trace effects to implement.

An OCaml implementation of our analysis is presented and discussed in [44], andis available for download [43]. The implementation includes both the HM style andconstraint subtyping systems, and the stack-based post-processing transformation ofeffects.

1.2 Organization of the Paper

In Sect. 2, we introduce the language modelλtrace, that includes dynamic traces in con-figurations and dynamic checks on traces. In Sect. 3, we define a language of traceeffects for static approximation of dynamic traces. In Sect. 4, we define a Hindley-Milner style polymorphic type system for assigning effects to programs. In Sect. 5, wegive a unification-based inference algorithm for automatically reconstructing programeffects. In Sect. 6 we define a more flexible constraint subtyping system and in Sect. 7we define an inference algorithm for reconstructing types in this system. In Sect. 8, wedefine an alternate stack-based version of the language and show how post-processinginferred effects can approximate traces in this variation. In Sect. 9, we develop an au-tomatic model-checking technique for verification of effects. In Sect. 10, we describeexamples of how the system can be applied to language-based security. We concludewith a discussion of related work and final summary in Sect. 11.

2 The Languageλtrace

In this Section we develop the syntax and semantics of our language modelλtrace.

2.1 Syntax

The syntax of the theoryλtrace is given in Fig. 1. The base values include booleans andthe unit value(). Expressionsletx = v in e are included to implement let-polymorphismin the type system (Sect. 4). Functions, writtenλzx.e, possess a recursive binding mech-anism wherez is the self variable. We assume the following syntactic sugarings:

e1 ∧ e2 , ∧e1e2 e1 ∨ e2 , ∨e1e2 λx.e , λzx.e z not free ine

λ .e , λx.e x not free ine e1; e2 , (λ .e2)(e1)

Page 4: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

4 Christian Skalka, Scott Smith, and David Van Horn

c ∈ C atomic constants

b ::= true | false boolean values

v ::= x | λzx.e | c | b | ¬ | ∨ | ∧ | () values

e ::= v | e e | ev(e) | if e then e else e | letx = v in e expressions

η ::= ε | ev(c) | η; η traces

E ::= [ ] | v E | E e | ev(E) | ifE then e else e evaluation contexts

Fig. 1.λtrace language syntax

Eventsev are named entities parameterized by constantsc (we treat only the unarycase in this presentation, but the extension ton-ary events is straightforward). Theseconstantsc ∈ C are abstract, withC formally defined as a countably infinite set of arbi-trary identifiers; this set could for example be strings or IP addresses. Ordered sequencesof these events constitute tracesη, which maintain the sequence of events experiencedduring program execution. We letη denote the string obtained from this sequence by re-moving delimiters (;). We distinguish a subset of eventsevφ identified by assertionsφ ina to-be-specified logical syntax (defined in Sect. 9). These arecheckevents, and the se-mantics will require that run-time checks succeed in order for computation to progress.We presuppose existence of a meaning functionΠ such thatΠ(φ(c), η) holds iff φ(c)is valid for η; we also leave the meaning functionΠ abstract until later (Sect. 9).

Parameterizing events and checks with constantsc allows for a more expressiveevent language; for example, in Sect. 10 we show how the parameterized privileges ofJava stack inspection can be encoded with the aid of these parameters.

2.2 Semantics

The operational semantics ofλtrace is defined in Fig. 2 via the call-by-value small stepreduction relations and→ on configurationsη, e, whereη is the run-time programevent trace. We write→? to denote the reflexive, transitive closure of→. Note thatin the eventreduction rule, an eventev(c) encountered during execution is added tothe end of the trace. Thecheckrule specifies that when a configurationη, evφ(c) isencountered during execution, it is appended to the end ofη like other events, and alsoφ(c) is required to be satisfied by the string(η evφ(c)), which is the concatenation ofηandevφ(c) (see Definition 3.1), according to our meaning functionΠ. The reasons fortreating checks as dynamic events is manifold; for one, some checks may ensure thatother checks have occurred in the trace. Also, this scheme will simplify the definitionof Π, as well as typing and verification. In case a check fails at runtime, execution is“stuck”; formally:

Definition 2.1. We say that a configurationη, e is stuck iff e is not a value and theredoes not existη′ ande′ such thatη, e→ η′, e′. If ε, e→? η, e′ andη, e′ is stuck, theneis said togo wrong.

The following example demonstrates the basics of syntax and operational semantics.

Page 5: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 5

η, (λzx.e)v η, e[v/x][λzx.e/z] (β)

η,¬true η, false (notT)

η,¬false η, true (notF)

η,∧ true η, λx.x (andT)

η,∧ false η, λ .false (andF)

η,∨ true η, λ .true (orT)

η,∨ false η, λx.x (orF)

η, if true then e1 else e2 η, e1 (ifT)

η, if false then e1 else e2 η, e2 (ifF)

η, letx = v in e η, e[v/x] (let)

η, ev(c) (η; ev(c)), () (event)

η, evφ(c) (η; evφ(c)), () if Π(φ(c), η evφ(c)) (check)

η,E[e] → η′, E[e′] if η, e η′, e′ (context)

Fig. 2.λtrace language semantics

Example 2.1.Let the functionf be defined as:

f , λzx.ifx then ev1(c) else (ev2(c); z(true))

Then, in the operational semantics, we have:

ε, f(false)→? ev2(c); ev1(c), ()

since the initial call tof will causeev2 to be added to the trace, followed by a recursivecall tof that hits its basis, where eventev1 is encountered.

3 Trace Effects

The goal of our static analysis is to conservatively approximate trace behavior of pro-grams, and to predict success or failure of program checks on the basis of this approx-imation. We will use a type system to reconstructtrace effects, which constitute theapproximation.

In essence, trace effectsH conservatively approximate tracesη that may developduring execution, by representing a set of traces containing at leastη. Trace effects aregenerated by the following grammar:

H ::= ε | h | ev(c) | H;H | H|H | µh.H trace effects

A trace effect may be an eventev(c), a sequencing of trace effectsH1;H2, a nondeter-ministic choice of trace effectsH1|H2, or a recursively bound trace effectµh.H thatfinitely represents the set of possibly infinite traces that may be generated by recur-sive functions. Trace effects may contain check eventsevφ(c), allowing verification of

Page 6: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

6 Christian Skalka, Scott Smith, and David Van Horn

checks at the right points in trace approximations. Noting that the syntax of tracesη isthe same as linear, variable-free trace effects, we abuse syntax and letη also range overlinear, variable-free trace effects, interpreting tracesη as the identical trace effect.

As mentioned, trace effects are interpreted as denoting sets of traces. More precisely,we define a Labelled Transition System (LTS) interpretation of trace effects as setsof strings over the alphabet of events plus a↓ symbol to denote termination; abusingterminology, we also call these strings traces. Traces may be infinite, because programsmay not terminate.

Definition 3.1. We writeθ to denote possibly↓ terminated strings over the alphabet ofevents:

s ::= ev(c) | ε | s sθ ::= s | s↓

We endow strings with an equational theory to interpretε as the empty string and stringconcatenation as usual:

s ε = s ε s = s (s1s2)s3 = s1(s2s3)

The symbolΘ is defined to range over prefix-closed sets of traces.

Trace effects generate traces by viewing effects as programs in a simple nondetermin-istic transition system.

Definition 3.2. The trace effect transition relation on closed traces effects is defined asfollows:

ev(c)ev(c)−−−→ ε H1|H2

ε−→ H1 H1|H2ε−→ H2 µh.H

ε−→ H[µh.H/h]

ε;H ε−→ H H1;H2s−→ H ′1;H2 if H1

s−→ H ′1

We formally determine the sets of tracesΘ associated with a closed trace effect in termsof the transition relation:

Definition 3.3. The interpretation of trace effects is defined as follows:

JHK = {s1 · · · sn | Hs1−→ · · · sn−→ H ′} ∪ {s1 · · · sn ↓ | H

s1−→ · · · sn−→ ε}

Any trace effect interpretation is clearly prefix-closed. In this interpretation, an infinitetrace is viewed as the set of its finite prefixes.

Note that prefix closure does not cause any loss of information, since the postpending of↓ to terminating traces allows them to be distinguished from their prefixes. In particular,this means that(H1;H2) 6= H1 for arbitrary closedH1 andH2 6= ε.

Equivalence of trace effects is defined via their interpretation, i.e.H1 = H2 iffJH1K = JH2K. This relation is in fact undecidable: traces are equivalent to Basic ProcessAlgebras (BPAs), as demonstrated in Sect. 9, and equivalence of BPAs is known to beundecidable [10].

Some trace effects contain occurrences of checks, i.e. their interpretation containstraces of the formθevφ(c). We definevalidity of effects in terms of the satisfiabilityof these checks, given their contextθ. Formally, if a trace is in the interpretation of aneffect, and that trace contains a check, the check must hold for its immediate prefix:

Page 7: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 7

Definition 3.4. A trace effectH is valid iff for all θevφ(c) ∈ JHK it is the case thatΠ(φ(c), θevφ(c)) holds.

3.1 Properties

Various properties of trace effect equivalence are enumerated as follows. The equiva-lences will be exploited for brevity and clarity in examples throughout the text, as wellas for later proofs:

Lemma 3.1. We note the following properties of trace effect equivalence for all closedH,H1,H2, andH3:

1. H|H = H2. ε;H = H = H; ε3. µh.H = H4. H1|H2 = H2|H1

5. H1; (H2;H3) = (H1;H2);H3

6. H1|(H2|H3) = (H1|H2)|H3

7. H1; (H2|H3) = (H1;H2)|(H1;H3)8. (H1|H2);H3 = (H1;H3)|(H2;H3)9. H ′[µh.H ′/h] = µh.H ′ for all closedµh.H ′.

10. Trace effect equivalence is homomorphic for all constructors

We also note some properties related to trace effect interpretation containment; theseproperties are important, since our type analyses will allowweakeningof trace effectsfor flexibility. That is, if a trace effectH approximates the traces generated by a pro-gram, andJHK ⊆ JH ′K, thenH ′ is also a sound approximation. Like equality, contain-ment is known to be undecidable.

Lemma 3.2. WritingH ⊆ H ′ iff JHK ⊆ JH ′K, the following properties hold:

1. H ⊆ H ′ is undecidable2. H ⊆ H|H ′3. IfH ⊆ H ′ thenH|H ′′ ⊆ H ′|H ′′ andH ′′;H ⊆ H ′′;H ′ andH;H ′′ ⊆ H ′;H ′′ for

all closedH ′′.4. IfH ⊆ H ′ then validity ofH ′ implies validity ofH.

4 Hindley-Milner Style Typing for λtrace

The syntax of types forλtrace is given in Fig. 3. This syntax is more liberal than whatis actually allowed in type derivations, for example function domain and range typescannot be trace effects or “bare” singletonss, and the three different kinds of variablesmust occur only in the appropriate positions. Formally, we define aswell-kindedonlythose type terms that have an interpretation in the ground tree model given in the senseof Definition 5.2 and Definition 5.3, below. Hereafter we restrict our presentation towell-kinded types. The syntax of types includes forms for booleans, unit, and function

Page 8: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

8 Christian Skalka, Scott Smith, and David Van Horn

α ∈ VSing, t ∈ VType, h ∈ VEff type variables

β ∈ VSing∪ VType∪ VEff

s ::= c | α singleton types

H ::= ε | h | ev(s) | H;H | H|H | µh.H trace effects

τ ::= β | s | {s} | H | τ H−→ τ | bool | unit types

σ ::= ∀β.τ type schemes

Γ ::= ∅ | Γ ;x : σ type environments

Fig. 3.λtrace type syntax

types of the formτ1H−→ τ2, wherelatenteffectsH represent the traces that may result

by use of the function. Events are side-effects, and so these function types are a formof effect type [40, 2]. Additionally, since events and predicates are parameterized, wemust be especially accurate with respect to our typing of singleton constants. Thus, weadopt a very simple form of singleton type{c} [38], where only atomic constants canhave singleton type.

Types contain three kinds of variables: regular type variablest, singleton type vari-ablesα, and trace effect type variablesh. The metavariableβ ranges over all kinds ofvariables. Universal type schemes∀β.τ bind any kind of type variable inτ , whereβis a vector of type variables. Note that let-polymorphism over types, singletons, andtrace effects is included in our system. We formally define some convenient notationfor vectors of variables:

Definition 4.1. Variable vectors, denotedβ, range over sequences of distinct variablesβ1 · · ·βn, with the empty vector denoted∅. Vectors are equivalent up to reordering;hence, we may treat vectorsβ1 · · ·βn as analogous sets{β1, . . . , βn}, in particularadapting notationβ ∈ β and β1 ∪ β2 and β1 ∩ β2 with the obvious meaning. We writeβ1#β2 iff β1 ∩ β2 = ∅. For any type schemeσ, we write fv(σ) to denote the freevariables inσ, extending the notation to environmentsΓ in the obvious manner. Wewrite τ as syntactic sugar for∀∅.τ .

Without loss of generality, we equate type schemes up toα-renaming and extraneousbindings. That is, we assume the following axiom:

∀β1β2.τ = ∀β1.τ if β2#fv(τ)

Source code type derivation rules forjudgementsΓ,H ` e : τ are given in Fig. 4,whereΓ is an environment of variable typing assumptions,H is the effect of the ex-pressione, andτ is the type ofe. To assign types to constants, we posit a constant typebinding environment∆ as follows.

Definition 4.2. Constantsc range over the set{(), true, false,¬,∨,∧} ∪ C. The bind-ing environment∆ contains bindings for all constants, consisting ofc : {c} for all

Page 9: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 9

VARΓ (x) = σ

Γ, ε ` x : σ

CONST

Γ, ε ` c : ∆(c)

EVENTΓ,H ` e : {s}

Γ,H; ev(s) ` ev(e) : unit

∀-INTROΓ, ε ` v : τ β#fv(Γ )

Γ, ε ` v : ∀β.τ

∀-ELIMΓ, ε ` v : ∀β.τΓ, ε ` v : τ [τ /β]

WEAKENΓ,H ′ ` e : τ H ′ v H

Γ,H ` e : τ

IFΓ,H1 ` e1 : bool Γ,H2 ` e2 : τ Γ,H2 ` e3 : τ

Γ,H1;H2 ` if e1 then e2 else e3 : τ

APP

Γ,H1 ` e1 : τ ′H3−−→ τ Γ,H2 ` e2 : τ ′

Γ,H1;H2;H3 ` e1e2 : τ

FIX

Γ ;x : τ1; z : τH−→ τ ′, H ` e : τ

Γ, ε ` λzx.e : τ ′H−→ τ

LETΓ, ε ` v : σ Γ ;x : σ,H ` e : τ

Γ,H ` letx = v in e : τ

Fig. 4.λtrace Hindley-Milner style typing rules

c ∈ C, and the following:

() : unit true : bool false : bool ¬ : boolε−→ bool

∧ : boolε−→ bool

ε−→ bool ∨ : boolε−→ bool

ε−→ bool

Type safety will be defined in terms ofvalid typing judgements, which are derivablejudgements where the top-level effect is valid. A subject reduction result will showthat effects assigned by type analysis are conservative approximations of program tracebehavior, while validity of top-level effects will guarantee success of run-time checks.

Definition 4.3. A derivable type judgementΓ,H ` e : σ is valid iff H is valid.

Example 4.1.Let f defined as in Example 2.1, and let:

H , (µh.ev1(c) | ev2(c);h); ev3(c′)

Then, the following judgements are derivable:

∅, ε ` f : boolµh.ev1(c)|ev2(c);h−−−−−−−−−−−→ unit ∅,H ` f(false); ev3(c′) : unit

4.1 Properties

One of the basic claims about our type system is that it isconservative, in that theaddition of trace effects is a conservative extension to an underlying Hindley-Milner

Page 10: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

10 Christian Skalka, Scott Smith, and David Van Horn

(HM) style let-polymorphic type system: by using weakening before each if-then-elsetyping, any derivation in the underlying effect-free type system may be replayed here.This result is formalized as follows.

Definition 4.4. We define the “event erasure” function eraseη on expressions as fol-lows:

eraseη(x) = x

eraseη(c) = c

eraseη(ev(c)) = ()eraseη(e1e2) = eraseη(e1)eraseη(e2)

eraseη(λzx.e) = λzx.eraseη(e)eraseη(if e1 then e2 else e2) = if eraseη(e1) then eraseη(e2) else eraseη(e3)

eraseη(letx = e1 in e2) = letx = eraseη(e1) in eraseη(e2)

We also define the “trace effect erasure” function eraseH on types as follows:

eraseH(τ) = τ τ ∈ {t,bool,unit, {s}}

eraseH(τ1H−→ τ2) = eraseH(τ1)→ eraseH(τ2)

The function eraseH is extended to type environmentsΓ in the obvious manner.

Definition 4.5. We writeΓ ` e : τ for judgements in a standard simple type systemwith let-polymorphism, e.g. that of [28], extended with singleton constants and ourCONST rule.

Lemma 4.1 (Conservativity).Γ,H ` e : τ is derivable iff eraseH(Γ ) ` eraseη(e) :eraseH(τ) is.

Proof. Straightforward by definition and induction on typing derivations. ut

Our type safety results are stated as follows. The proof of each is immediate byconservation of the HM style system in the constraint subtyping system presented inSect. 6, Lemma 6.3, and analogous results in that system, which are proven in detail inSect. 6.

Theorem 4.1 (Type Safety).If Γ,H ` e : τ is valid for closede, thene does not gowrong.

Theorem 4.2 (Progress).If Γ,H ` e : τ is derivable for closede and η, e is irre-ducible withη;H valid, thene is a value.

A subject reduction result for the HM style system can also be proved via Lemma 6.3and subject reduction in the constraint subtyping system.

Lemma 4.2 (Subject Reduction).If Γ,H ` e : τ is derivable for closede andη, e η′, e′, thenΓ,H ′ ` e′ : τ is derivable withη′;H ′ ⊆ η;H.

Page 11: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 11

VARΓ (x) = ∀β.τ/C

Γ, ε `β′ x : (τ/C)[β′/β]

CONST

Γ, ε `∅ c : ∆(c)/true

EVENTΓ,H `β e : τ/C

Γ,H; ev(α) `β∪{α} ev(e) : unit/C ∧ τ v {α}

IFβ1#β2#β3 β = β1β2β3 ∪ {t}

Γ,H1 `β1e1 : τ1/C1 Γ,H2 `β2

e2 : τ2/C2 Γ,H3 `β3e3 : τ3/C3

Γ,H1;H2|H3 `β if e1 then e2 else e3 : t/C1 ∧ C2 ∧ C3 ∧ τ1 v bool∧ τ2 v t ∧ τ3 v t

APPβ1#β2 Γ,H1 `β1

e1 : τ1/C1 Γ,H2 `β2e2 : τ2/C2

Γ,H1;H2;h `β1β2∪{t,h} e1 e2 : t/C1 ∧ C2 ∧ τ1 v τ2h−→ t

FIX

Γ ;x : t; z : th−→ t′, H `β e : τ/C

Γ, ε `β∪{t,h,t′} λzx.e : th−→ t′/C ∧ τ v t′ ∧H v h

LETβ1#β2 Γ, ε `β1

v : τ ′/D Γ ;x : ∀β1.τ′/D,H `β2

e : τ/C

Γ,H `β1β2letx = v in e : τ/C ∧D

Fig. 5.λtrace type constraint inference rules

A significant corollary of this result is one of our guiding intuitions: that trace effectsconservatively approximate the set of possible run-time traces, formalized as follows.Prefix closure of effect interpretation ensures that traces produced at any point in thecomputation, not just at termination, will be approximated.

Corollary 4.1. If Γ,H ` e : τ is derivable for closede andε, e→? η, e′ thenη ∈ JHK.

5 Unification-Based Type Inference

In this section we show that a type inference algorithm exists for the HM style typesystem forλtracepresented in the previous section. The type inference algorithm will bepartly based on unification, in keeping with the HM subset of the system, but the pres-ence of effect weakening requires a simple form of constraint solution. Thus, our ap-proach to inference will be constraint based, with type constraints interpreted as equalityconstraints, and effect constraints interpreted as containment constraints. In addition tobeing an effective approach in this context, we will see in Sect. 7 that it allows the sametype inference algorithm to be used for a subtyping system, by imposing a subtypinginterpretation of type constraints, and introducing a new constraint solution algorithm.

Page 12: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

12 Christian Skalka, Scott Smith, and David Van Horn

That is, type inference is modular with respect to interpretation of constraints, in thespirit of systems such as HM(X) [39].

5.1 Syntax and meaning of constraints

We begin by defining the syntax of constraints, wherev is the constraint relation be-tween types.

Definition 5.1. ConstraintsC are defined as follows:

C ::= true | τ v τ | C ∧ C

Constraints are required to agree in kind, i.e. for any constraintτ v τ ′, we require thatτ : k andτ ′ : k for somek.

The appropriate meaning of constraints is obtained by interpretation in a modelT,which for the HM system we define as a universe of monotypes, endowed with a par-tial order4 that is an equality relation on types, and a containment relation on effects.Later, to obtain a subtyping interpretation of constraints, we will redefineT and4 ap-propriately.

Definition 5.2 (Ground Type Model). Let T be the set ofground, or variable free,typesτ , denotedτ and generated by the following grammar, whereH ranges overvariable free trace effects:

τ ::= unit | bool | {c} | H | τ H−→ τ

Further,T is endowed with a partial order4 axiomatized as follows:

JHK ⊆ JH ′KH 4 H ′

Definition 5.3 (Interpretation of Constraints). Interpretationsρ are total mappingsfrom type variablesβ to T. We impose the sanity condition that each kind of type vari-able is mapped to elements ofT of the appropriate form, i.e. for allα, t, h, ρ we requirethat ρ(α) is a singletonc, andρ(h) is a closed effectH, andρ(t) is one of the otherelement forms. Interpretations are extended to types and effects as in Fig. 6, where inabuse of notation the interpretation of effects are parameterized by setshs of effect vari-ables, to prevent substitution ofµ-bound variables. The relationρ ` C, pronouncedρsatisfiesor solvesC, is axiomatized as follows:

ρ ` trueρ(τ1) 4 ρ(τ2)ρ ` τ1 v τ2

ρ ` C ρ ` Dρ ` C ∧D

The relationC D holds iffρ ` C impliesρ ` D for all interpretationsρ. ConstraintsC andD areequivalent, writtenC = D, iff C D andD C.

Page 13: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 13

ρ(h, hs) = ρ(h) h 6∈ hsρ(h, hs) = h h ∈ hs

ρ(ev(s), hs) = ev(ρ(s))

ρ(ε, hs) = ε

ρ(H1;H2, hs) = ρ(H1, hs); ρ(H2, hs)

ρ(H1|H2, hs) = ρ(H1, hs)|ρ(H2, hs)

ρ(µh.H, hs) = µh.ρ(H,hs ∪ {h})

ρ(c) = c

ρ({s}) = {ρ(s)}ρ(unit) = unit

ρ(bool) = bool

ρ(τ1H−→ τ2) = ρ(τ1)

ρ(H)−−−→ ρ(τ2)

ρ(H) = ρ(H,∅)

Fig. 6. Interpretations extended to types and effects

5.2 Type inference and constraint solution

Type inference judgments are of the formΓ,H `β e : τ/C, whereH, τ , andC are thereconstructed top level effect, type, and constraint, andβ are the variables introducedduring the derivation. Type schemes are now constrained, written∀β.τ/C, and typeenvironmentsΓ now bind variables to constrained type schemes. We writeτ as short-hand for∀∅.τ/true. Type inference rules are defined in Fig. 5; they are deterministicexcept for arbitrary choice of variables. We callcanonicalthose derivations where freshvariables are chosen whenever possible, where a variableβ is fresh with respect a judge-mentΓ,H `β e : τ/C iff it occurs nowhere in the judgement. Note that disjointnessconditions on fresh variables chosen in subderivation are imposed in derivations, bythe IF, APP, and LET rules, ensuring “global” freshness of variable choice in canonicalderivations.

To automatically obtain HM style types forλtraceexpressions, it is also necessary toconvert inferred types and constraints into unified, constraint-free form. To accomplishthis, we define a unification algorithm, extended to also apply to effect constraints.Given a constraint generated by type inference, the resulting algorithm will generate atype substitution that solves the constraint.

Definition 5.4. Substitutions, written[τ1/β1, . . . , τn/βn], are mappings from type vari-ables to types, extended to types, type schemes, type environments, and constraints inthe usual manner. We writedom([τ1/β1, . . . , τn/βn]) to meanβ1 · · ·βn. We letψ rangeover substitutions[τ1/β1, . . . , τn/βn], though the former is prefix notation while the lat-ter is postfix. We writeψ1 ◦ψ2 to denote the substitutionψ such thatψ(τ) = ψ1(ψ2(τ))for all τ . Extending the vector notation of Definition 4.1, we write[τ /β] to denote[τ1/β1, . . . , τn/βn] whereτ = τ1 · · · τn andβ = β1 · · ·βn.

Page 14: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

14 Christian Skalka, Scott Smith, and David Van Horn

unify(true) = true

unify(C ∧ τ v τ) = unify(C)

unify(C ∧ β v τ) = fail if β ∈ fv(τ), elseunify(C[τ/β]) ◦ [τ/β]

unify(C ∧ τ v β) = fail if β ∈ fv(τ), elseunify(C[τ/β]) ◦ [τ/β]

unify(C ∧ {s1} v {s2}) = unify(C ∧ s1 v s2)

unify(C ∧ τ1h−→ τ2 v τ ′1

h′−→ τ ′2) = unify(C ∧ h v h′ ∧ τ ′1 v τ1 ∧ τ2 v τ ′2)

Fig. 7.Constraint set unification

soln(C) = letC1, C2 = hsplit(C) andψ1 = unify(C1) in solnH(ψ1(C2)) ◦ ψ1

hsplit(C) = C1, C2 whereset(C2) = {H1 v H2 |H1 v H2 ∈ C}andC1 = C − C2

bounds(h,C) = H1| · · · |Hn where{H1, . . . , Hn} = {H | H v h ∈ C}

solnH(∅) = ∅

solnH(C) = letψ = [(µh.bounds(h,C))/h] in

solnH(ψ(C − {H v h | H v h ∈ C})) ◦ ψ

Fig. 8.Unification based solution

Since any solution of a constraintC must unify the type constraints inC, and alsosatisfy the effect constraints inC, constraint solutions need to be defined generally, asfollows:

Definition 5.5. A substitutionψ is asolutionof a constraintC iff ρ ` ψ(C) for all ρ.

To define how to construct solutions of constraint, here and for the subtyping versionof our type analysis presented later, it is useful to interpret constraints as sets, rather thanconjunctions, of atomic constraints. Thus, we introduce the following notation.

Definition 5.6. Let C range over atomic constraints, i.e.:

C ::= true | τ v τ

and givenC = C1 ∧ · · · ∧ Cn, let set(C) ={C1, . . . , Cn

}. Then:

C ⊆ D ⇐⇒ set(C) ⊆ set(D)C ∈ C ⇐⇒ C ∈ set(C)

C1 − C2 = D ⇐⇒ set(C1)− set(C2) = set(D)

Page 15: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 15

Now, since effect containment is known to be undecidable, as observed in Sect. 3,it seems there can be no general constraint solution algorithm. However, type inferencegenerates effect constraints of a particular form, in particular it yields a system of lowerboundsH v h on effect variablesh, as is immediately demonstrated by observationof the type inference rules in Fig. 5. For this restricted form of effect constraints, thereexists a solution algorithmsolnH, defined in Fig. 8, that joins lower bounds in thesolution of effect variablesh. By composing this with the unification algorithmunifydefined in Fig. 7, a constraint solution algorithmsoln is obtained to for constraintsgenerated by type inference. Note that inferred constraints need to be split into type andeffect components byhsplit , before application ofunify the former andsolnH to thelatter. Soundness of the type inference technique can be stated as follows; a proof ofthis result is given in [44].

Theorem 5.1 (Soundness of Inference).Given closede; then if∅,H `β e : τ/C isderivable, andψ = soln(C), then∅, ψ(H) ` e : ψ(τ) is derivable.

6 Constraint Subtyping for λtrace

The HM style system developed in the previous section suffers from a certain degree ofimprecision, due to the interpretation ofv as equivalence on types. For example, given:

f , λx.(if true thenλ .ev1(c) elsex);x

observe that the types ofx andλ .ev1(c) are forced to be equivalent by the typing rulefor conditionals, hence we derive:

f : ∀ht.(t ev1(c)|h−−−−−→ unit) ε−→ (tev1(c)|h−−−−−→ unit)

In other words, the effect ofλ .ev1(c) is forced to be subsumed by the effect ofx,resulting in a lack of precision, further illustrated by application off :

f(λ .ev2(c)) : tev1(c)|ev2(c)−−−−−−−−→ unit

In this section we propose a more expressive system based on subtyping constraints.The subtyping relation will allow types, as well as effects, to be weakened as necessary.In treating the above example, the type ofx will not be forced to be equivalent toλ .ev1(c), but can be weakened via subsumption to allow typing of the conditionalexpression in the body off , while retaining a purely abstract latent effect onx in amost general typing off . The essence of the subtyping relation is an adaptation ofeffect weakening to latent effect on function types, for example:

th−→ unit v t

ev1(c)|h−−−−−→ unit

Thus we can derive a more precise typing forf :

f : ∀ht.(t h−→ unit) ε−→ (t h−→ unit)

Page 16: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

16 Christian Skalka, Scott Smith, and David Van Horn

and also forf(λ .ev2(c)):

f(λ .ev2(c)) : tev2(c)−−−−→ unit

Subtleties of the relation include contravariance/covariance in function domain/rangetypes, and treatment of free variables in related types; these issues are resolved inSect. 6.2 below.

The use of a constraint representation of types has several distinct benefits in thissetting. For one, constraints may be recursive, allowing typing of self-referential expres-sions such asλx.xx. Furthermore, constraints allow a representation of conjunctive anddisjunctive types [14], without requiring conjunctive and disjunctive type syntax and in-terpretation. While disjunction can be represented in effect terms via the nondetermin-istic choice operator (|), a term representation of effect conjunction would require theaddition of a parallel-and operation in effects, which is known to significantly increasethe complexity of model-checking [10]. In short, a constraint representation simplifiesthe subtyping analysis; while it yields a more cumbersome, less readable typing thana unified representation, model-checkable effects can still be extracted, as we show inSect. 7. Since our goal is an automatic program analysis tool, this is agreeable.

6.1 Logical Subtyping Judgements and Derivations

Logical subtyping judgements are of the formΓ,C,H ` e : τ , with all syntactic formsas defined in previous sections. In any such judgement, we refer toC andH as thetop-levelconstraint and effect. The constant type binding environment∆ is also as definedpreviously. Note that constraintsC, previously occurring only in inference judgements,now occur in logical judgements; of course, a significant difference in the current sys-tem is the interpretation ofv as a subtyping relation, formalized below in Sect. 6.2.Note well that we adopt the interpretation of constraints given in Definition 5.3; sub-typing will be realized purely through a redefinition of the modelT in Definition 6.3.

To allow more flexibility in the typing of singleton constants, we make a smallextension to the type and effect language:

Definition 6.1. We extend the language of singleton types in Fig. 3 with the forms|s.Additionally, we define the semantics of an effectev(c1|c2) as equivalent toev(c1)|ev(c2).

Anticipating the interpretation, the meaning of a types1|s2 subsumes the meaning ofs1 ands2– i.e., it is a disjunctive singleton type.

While the logical typing rules are based on previous subtyping constraint systemssuch as [14] and [33], there is a difference, in that in any judgementΓ,C,H ` e : τ ,the scope of quantified type variablesβ in type schemes inΓ effectively extend toC;in particular, noting the form of the rule∀-ELIM , we define:

Definition 6.2. WriteC [τ /β] iff C C[τ /β].

Thus, given a top-level constraintC , h1 v h2, the type scheme∀h1h2.unith1−→ unit

is more general than∀h1.unith1−→ unit, even thoughh2 does not occur in the quan-

tified type. Observe that given the former type scheme, the rule∀-ELIM essentially

Page 17: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 17

VARΓ (x) = σ

Γ,C, ε ` x : σ

CONST

Γ,C, ε ` c : ∆(c)

EVENTΓ,C,H ` e : {s}

Γ,C,H; ev(s) ` ev(e) : unit

∀-INTROΓ,C, ε ` v : τ β#fv(Γ )

Γ,C, ε ` v : ∀β.τ

∀-ELIMΓ,C, ε ` v : ∀β.τ C [τ /β]

Γ,C, ε ` v : τ [τ /β]

SUBΓ,C,H ′ ` e : τ ′ C τ ′ v τ C H ′ v H

Γ,C,H ` e : τ

IFΓ,C,H1 ` e1 : bool Γ,C,H2 ` e2 : τ Γ,C,H2 ` e3 : τ

Γ,C,H1;H2 ` if e1 then e2 else e3 : τ

APP

Γ,C,H1 ` e1 : τ ′H−→ τ Γ,C,H2 ` e2 : τ ′

Γ,C,H1;H2;H ` e1 e2 : τ

FIX

Γ ;x : τ ′; z : τ ′H−→ τ, C,H ` e : τ

Γ,C, ε ` λzx.e : τ ′H−→ τ

LETΓ,C, ε ` v : σ Γ ;x : σ,C,H ` e : τ

Γ,C,H ` letx = v in e : τ

Fig. 9.λtrace constraint typing, logical rules

imposes monomorphism onh1 due to its relation withh2 specified inC, whereas thelatter type scheme allows any instantiation[H1/h1] as long as there also exists a sub-stitution [H2/h2] such thatC H1 v H2. This state of affairs is implicitly due to asimplification we have made in the type system, where all relevant typing constraintsare subsumed in the top-level constraintC. In the type inference system presented inSect. 7, where constraints must be reconstructed, rather than givena priori, we willreturn to constrained type scheme forms.

The logical subtyping derivation rules defined in Fig. 9 are quite similar to the HMstyle rules defined in Fig. 4, other than the rule SUB, which incorporates type subsump-tion as well as weakening of top-level effects. As mentioned above, type subsumptionallows weakening of latent effects on function types. The meaning of the subtypingrelation and validity of type judgements is defined in terms of constraint solutions, for-malized in the next section.

6.2 Interpretation of Subtyping Constraints

Following [42], subtyping is defined via interpretation in a regular tree model endowedwith aprimitive subtypingrelation, a technique that allows us to accommodate recursiveconstraints. The relation is defined inductively via finite approximations. Intuitively, the

Page 18: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

18 Christian Skalka, Scott Smith, and David Van Horn

ϕ is finite

⊥ 4fin ϕ

ϕ is finite

ϕ 4fin >ϕ 4fin ϕ|ϕ′ ϕ 4fin ϕ

′|ϕϕ 4fin ϕ

{ϕ} 4fin {ϕ′}

JHK ⊆ JH ′KH 4fin H

′ϕ′1 4fin ϕ1 ϕ2 4fin ϕ

′2 H 4fin H

′ ϕ1, ϕ′1, ϕ2, ϕ

′2 finite

ϕ1H−→ ϕ2 4fin ϕ

′1H−→ ϕ′2

ϕ |n 4fin ϕ′ |n for all n ∈ Nϕ 4 ϕ′

Fig. 10.Primitive subtyping for regular trees

>∅,⊥∅ : Type unit∅ : Type bool∅ : Type sc∅ : Sing {sc}∅ : Type

H∅ : Eff (· ·−→ ·)Type,Eff,Type : Type

Fig. 11.Kinding rules for regular tree constructors

subtyping relation is invariant onbool andunit types, is contravariant (resp. covariant)on the domain (resp. range) types of functions, and is covariant on latent function ef-fects. As before, the relationv on trace effects is defined via set containment in the LTSinterpretation of related effects.

Definition 6.3 (Regular Tree Model).Let thetree constructor kindsbe defined as:

k ::= Type| Eff | Sing

and letsignaturesς range over ordered sequences of kinds, where∅ denotes the emptysequence andς(n) denotes the 0-indexednth kind in ς. The alphabetL of tree con-structorstc is built from the following grammars:

sc ::= c | sc|sctc ::= > | ⊥ | sc | unit | bool | {sc} | H | · ·−→ ·

where each element of the alphabet is indexed by a signature, writtentcς , and must bewell-kindedaccording to the rules given in Fig. 11.

A treeϕ is a partial function from finite sequences (paths) π of natural numbersN? to L such thatdom(ϕ) is prefix-closed. Furthermore, for allπn ∈ dom(ϕ), with

tcς = ϕ(π), it is the case thatϕ(πn) : ς(n). Thesubtree atπ ∈ dom(ϕ) is the functionλπ′.ϕ(ππ′), while |π| is the level of that subtree. A tree isregular iff the set of itssubtrees is finite, and we defineT as the set of regular trees overL.

A partial order overT is then defined via an approximate relation over finiteϕ ∈ T.First, define alevel-n cutϕ | n for ϕ ∈ T as the finite tree obtained by replacing all

Page 19: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 19

subtrees at leveln of ϕ with>. Then,4fin is the partial order over finiteϕ ∈ T axiom-atized in Fig. 10, and4 is the partial order overT approximated by4fin axiomatizedin Fig. 10.

By retaining Definition 5.3 withT and4 refigured in this manner, and extend-ing interpretations as defined in Fig. 6 to disjunctive singleton types asρ(s1|s2) =ρ(s1)|ρ(s2), we obtain a subtyping interpretation of constraints. We immediately notethat this imposes transitivity and reflexivity onv:

Lemma 6.1. The relationv is transitive and reflexive, by which we meanC τ v τ ,andC τ1 v τ2 ∧ τ2 v τ3 impliesC τ1 v τ3.

It also is useful to characterize what sort of types cannot be placed in av relation,especially to establish a canonical forms result (Lemma 6.14).

Lemma 6.2. Let � be the least symmetric relation on types (pronounced “clasheswith”) axiomatized by the following relational schemas:

unit� bool unit� {s} unit� τ1H−→ τ2 bool� {s} bool� τ1

H−→ τ2

{s} � τ1H−→ τ2

If C is solvable then for allτ1, τ2 such thatτ1 � τ2 it is the case thatC 6 τ1 v τ2.

Given our interpretation of constraints, we can now define validity of type judge-ments. Note that top level effects may contain free variables that must be interpreted viatop level constraints in order to ascertain validity of expression effects.

Definition 6.4. A judgementΓ,C,H ` e : τ is satisfiableiff it is derivable andC hasa solution. The judgement isvalid iff it is satisfiable and there exists a solutionρ of Csuch thatρ(H) is valid.

6.3 Properties

In this section we demonstrate our type safety and progress results, which along withcorrectness of type reconstruction will constitute the main results of this paper. The re-sult proceeds via a subject reduction argument, modified to account for trace effects.Type safety is explicitly demonstrated for the constraint subtyping system; to allowapplication to the unified system of Sect. 4, we demonstrate the following conserva-tivity result. Note that this also allows conservativity of Hindley-Milner typingsa laLemma 4.1 to be extended to constraint subtyping.

Lemma 6.3. If Γ,H ` e : τ is derivable, then so isΓ, true,H ` e : τ .

Proof. Straightforward by induction and case analysis on the last rule instance in thederivation ofΓ,H ` e : τ . Each derivation step inΓ,H ` e : τ can be mimicked bya same-named rule instance in the constraint subtyping system, other than instances ofWEAKEN, which can be simulated by instances of SUB, by reflexivity ofv and since itis easy to show thatH v H ′ impliesC H v H ′ for all C. ut

Page 20: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

20 Christian Skalka, Scott Smith, and David Van Horn

In later proofs the following observations about effect subtyping will be important;since interpretation of effect subtyping is defined in terms of containment in the the LTSsemantics defined in Sect. 3, the stated properties follow by Lemma 3.2.

Lemma 6.4. The following properties hold:

1. C H v H|H ′2. If C H v H ′ thenC H|H ′′ v H ′|H ′′ andC H ′′;H v H ′′;H ′ andC H;H ′′ v H ′;H ′′.

On the way to proving type safety and progress, we demonstrate a suite of standardresults for the current type system. This includes weakening and instantiation; bothproperties follow in a similar manner to corresponding results in [33]:

Lemma 6.5 (Weakening).If Γ,C,H ` e : τ is derivable andC ′ C, then so isΓ,C ′,H ` e : τ by a derivation of the same structure.

Lemma 6.6 (Instantiation). If Γ,C,H ` e : τ is derivable, then so is the judgementψ(Γ ), ψ(C), ψ(H) ` e : ψ(τ) by a derivation of the same structure.

Although the following Lemma seems obscure, it brings to light some subtle issuesrelated to polymorphism and generalization, including the requirement that top-leveleffects beε for generalization and instantiation, and that generalization cannot be per-formed on free environment variables. It also highlights the soundness of generalizationover variables in the top-level constraint, provided the requirements on instantiation. Inessence, the result shows that the∀ introduction and elimination forms do not allowovergeneralization.

Lemma 6.7. Consecutive instances of∀-INTRO and∀-ELIM may be suppressed.

Proof. Assume the following derivation structure:

Γ,C, ε ` e : τ β#fv(Γ )Γ,C, ε ` e : ∀β.τ C [τ /β]

Γ,C, ε ` e : τ [τ /β]

whereΓ,C, ε ` e : τ is derivable by assumption. ThusΓ [τ /β], C[τ /β], ε[τ /β] ` e :τ [τ /β] is derivable by a derivation of the same structure, by Lemma 6.6. Butε[τ /β] =ε, andΓ [τ /β] = Γ since β#fv(Γ ) by assumption, therefore the result follows byLemma 6.5 sinceC C[τ /β] by assumption and Definition 6.2. ut

The following result allows normalization of type derivations. When inducting onthe structure of type derivations, normal form derivations allow type judgements to beinverted; their subderivations can be deconstructed from root judgements, given theform of the root expression.

Lemma 6.8 (Normalization).If Γ,C,H ` e : τ is derivable, then it must follow by aninstance ofSUB from a judgementJ such that:

i. if e = λzx.e′ thenJ follows byFIX ;

Page 21: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 21

ii. if e = e1e2 thenJ follows byAPP;iii. if e = if e1 then e2 else e3 thenJ follows byIF;iv. if e = ev(e′) thenJ follows byEVENT;v. if e is one oftrue, false, (),∨,∧,¬, c, thenJ follows byCONST;

vi. if e = x thenJ follows byVAR and∀-ELIM ;vii. if e = (letx = v in e′) theJ follows byLET.

Proof. By Lemma 6.7, any consecutive instances of∀-INTRO and∀-ELIM can be sup-pressed. In effect, this allows us to restrict all instances of∀-ELIM to immediatelyfollow instances of VAR, and all instances of∀-INTRO to immediately precede LET.Furthermore, by Lemma 6.1 it is easy to show that consecutive instances of SUB canbe collapsed into a single instance, and due to reflexivity of SUB, trivial instances ofSUB can be inserted anywhere in a derivation other than following∀-INTRO. Since anyderivation of a judgementΓ,C,H ` e : τ must contain a syntax-directed rule instancecorresponding to the form ofe, with a judgementJ as the consequence, the resultfollows by suppressing, collapsing, or inserting non-syntax-directed rule instances asappropriate betweenJ andΓ,C,H ` e : τ . ut

Corollary 6.1. If Γ,C,H ` v : τ is derivable, then so isΓ,C, ε ` v : τ ′ with C τ ′ v τ andC ε v H.

Proof. Straightforward by the previous Lemma, and by observing that if a judgementΓ,C,H ′ ` v : τ ′ follows by a syntax-directed rule applicable to a valuev, thenH ′ = ε.

ut

In order to demonstrate thelet andβ reduction cases of subject reduction, we provea values substitution Lemma as follows.

Lemma 6.9 (Substitution).If both Γ ;x : σ′, C,H ` e : σ andΓ,C, ε ` v : σ′ arederivable, then so isΓ,C,H ` e[v/x] : σ.

Proof. By induction on the derivation ofΓ ;x : σ′, C,H ` e : σ and case analysison the last step in the derivation. We restrict our consideration to the most interestingcases.

Case∀-INTRO. In this caseσ = ∀β.τ , where by definition of∀-INTRO we canreconstruct:

Γ ;x : σ′, C,H ` e : τ β#fv(Γ ;x : σ′)Γ ;x : σ′, C,H ` e : ∀β.τ

But by the induction hypothesis the judgementΓ,C,H ` e[v/x] : τ is derivable,and since clearly fv(Γ ) ⊆ fv(Γ ;x : σ′) thereforeβ#fv(Γ ), so this case holds via aninstance of∀-INTRO.

Case VAR. In this casee = y, H = ε, and by definition of VAR we have that(Γ ;x : σ′)(y) = σ. Now, suppose on the one hand thatx 6= y. Thene[v/x] = y, andΓ (y) = σ, so this case holds via an instance of VAR. Suppose on the other hand thatx = y; thene[v/x] = v andσ = σ′, so the result follows by an assumption of theLemma.

Page 22: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

22 Christian Skalka, Scott Smith, and David Van Horn

Case FIX . In this casee = λzy.e′ andσ = τ1

H′−−→ τ2 andH = ε, and by definitionof FIX we can reconstruct:

Γ ;x : σ′; y : τ1; z : τ1H′−−→ τ2, C,H

′ ` e′ : τ2

Γ ;x : σ′, C, ε ` λzy.e′ : τ1H′−−→ τ2

Supposing thatx 6= y andx 6= z, it is the case that:

Γ ;x : σ′; y : τ1; z : τ1H′−−→ τ2 = Γ ; y : τ1; z : τ1

H′−−→ τ2;x : σ′

Hence the following is derivable by the induction hypothesis:

Γ ; y : τ1; z : τ1H′−−→ τ2, C,H

′ ` e′[v/x] : τ2

and by FIX :

Γ ; y : τ1; z : τ1H′−−→ τ2, C,H

′ ` e′[v/x] : τ2

Γ ;x : σ′, C, ε ` λzy.(e′[v/x]) : τ1H′−−→ τ2

so the result follows, sinceλzy.(e′[v/x]) = e[v/x] by definition of substitution. Sup-posing thatx = y, it is the case that:

Γ ;x : σ′; y : τ1; z : τ1H′−−→ τ2 = Γ ; y : τ1; z : τ1

H′−−→ τ2

ande[v/x] = v by definition of substitution, so we can reconstruct by FIX :

Γ ; y : τ1; z : τ1H′−−→ τ2, C,H

′ ` e′ : τ2

Γ,C, ε ` (λzy.e′)[v/x] : τ1H′−−→ τ2

The result follows similarly supposing thatx = z. ut

Type safety ultimately relies on the preservation of type validity by→?. Since therelation→? is predicated on both and→ forms of reduction, we therefore need toprove subject reduction results for each form. First, for :

Lemma 6.10 (Subject Reduction ). If Γ,C,H ` e : τ is derivable andη, e η′, e′, thenΓ,C,H ′ ` e′ : τ is derivable withC η′;H ′ v η;H.

Proof. By induction on the derivation ofΓ,C,H ` e : τ and case analysis on the ruleform ofη, e η′, e′. We restrict our consideration to the most interesting representativecases.

Caseβ. The following assertions hold by assumption in this subcase:

e = (λzx.e′′)v e′ = e′′[v/x][λzx.e′′/z] η′ = η

By Lemma 6.8, reconstruct the following, moving from the root upwards; by SUB:

Γ,C,H1;H2;H3 ` (λzx.e′′)v : τ2 C τ2 v τ C H1;H2;H3 v HΓ,C,H ` (λzx.e′′)v : τ

Page 23: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 23

and by APP:

Γ,C,H1 ` λzx.e′′ : τ1H3−−→ τ2 Γ,C,H2 ` v : τ1

Γ,C,H1;H2;H3 ` (λzx.e′′)v : τ2

and by SUB:

Γ,C, ε ` λzx.e′′ : τ ′1H′3−−→ τ ′2 C τ ′1

H′3−−→ τ ′2 v τ1H3−−→ τ2 C ε v H1

Γ,C,H1 ` λzx.e′′ : τ1H3−−→ τ2

and by FIX :

Γ ;x : τ ′1; z : τ ′1H′3−−→ τ ′2, C,H

′3 ` e′′ : τ ′2

Γ,C, ε ` λzx.e′′ : τ ′1H′3−−→ τ ′2

and by SUB and Corollary 6.1:

Γ,C, ε ` v : τ3 C ε v H2 C τ3 v τ1Γ,C,H2 ` v : τ1

Now, observe that by contravariance ofv in function domain types and transitivity ofvwe haveC τ3 v τ ′1, hence by SUB and the above we can deriveΓ,C,H2 ` v : τ ′1, soby successive applications of Lemma 6.9 we have thatΓ,C,H ′3 ` e′ : τ ′2 is derivable.ButC H ′3 v ε; ε;H ′3 by Lemma 3.1, and since by the above and definition ofv:

C H ′3 v H3 C ε v H1 C ε v H2

therefore by Lemma 6.4:C H ′3 v H1;H2;H3

and sinceC H1;H2;H3 v H andC τ ′2 v τ by the above and transitivity ofv,by SUB:

Γ,C,H ′3 ` e′ : τ ′2 C τ ′2 v τ C H ′3 v HΓ,C,H ` e′ : τ

so this case holds.Caselet. In this casee = letx = v in e0 ande′ = e0[v/x] andη = η′ by definition.

By Lemma 6.8, reconstruct the following; by SUB:

Γ,C,H0 ` letx = v in e0 : τ0 C H0 v H C τ0 v τΓ,C,H ` letx = v in e0 : τ

and by LET:Γ,C, ε ` v : σ Γ ;x : σ,C,H0 ` e0 : τ0

Γ,C,H0 ` letx = v in e0 : τ0

But thenΓ,C,H0 ` e′ : τ0 is derivable by Lemma 6.9, hence by the above and SUB:

Γ,C,H0 ` e′ : τ0 C H0 v H C τ0 v τΓ,C,H ` e′ : τ

Page 24: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

24 Christian Skalka, Scott Smith, and David Van Horn

so this case holds.Caseevent. In this casee = ev(c) ande′ = () andη′ = η; ev(c). By Lemma 6.8

and definition of the SUB, EVENT, and CONST we can reconstruct:

Γ,C,H ′; ev(s) ` ev(c) : unit C unitv τ C H ′; ev(s) v HΓ,C,H ` ev(c) : τ

and:Γ,C, ε ` c : {c} C {c} v {s} C ε v H ′

Γ,C,H ′ ` c : {s}Γ,C,H ′; ev(s) ` ev(c) : unit

But then by applications of CONST and SUB:

Γ,C, ε ` () : unit C unitv τ C ε v H ′

Γ,C,H ′ ` () : τ

and sinceC {c} v {s} by the above, thereforeC c v s and henceC ev(c) vev(s) by Definition 5.3, thus by Lemma 6.4 we haveC η; ev(c);H ′ v η; ev(s);H ′,so this case holds. ut

Before proving subject reduction for→, we need to establish some typing resultsrelated to evaluation contexts. Firstly, ife is a redex, then the effect ofE[e] shouldreflect that the trace predicted fore is the “first effect that will happen” in the evaluationof E[e]. Formally, we characterize this as follows:

Lemma 6.11 (Context Inversion).If Γ,C,H ` E[e] : τ is derivable for closedE[e],then there existsH1;H2 such thatΓ,C,H1;H2 ` E[e] : τ is derivable with a sub-derivation concluding inΓ,H1 ` e : τ ′ for e in the hole, whereC H1;H2 v H.

Proof. By induction onE. In the basisE = [] andE[e] = e so the result follows byassumption and Lemma 3.1, takingH2 = ε. Otherwise, the remaining forms ofE–E′e′, vE′, ifE′ then e1 else e2, andev(E′)– ensure thatH will at least reflect that theeffect ofe “happens first”. TakingE = E′e′ for example, so thatE[e] = E′[e]e′, byLemma 6.8 and SUB and APPwe can reconstruct:

Γ,C,H ′1;H ′2;H ′3 ` E′[e]e′ : τ ′ C τ ′ v τ C H ′1;H ′2;H ′3 v HΓ,C,H ` E′[e]e′ : τ

and:

Γ,C,H ′1 ` E′[e] : τ1H′3−−→ τ2 Γ,C,H ′2 ` e′ : τ1

Γ,C,H ′1;H ′2;H ′3 ` E′[e]e′ : τ ′

But then by the induction hypothesis, there existsH ′′2 such thatΓ,C,H1;H ′′2 ` E′[e] :

τ1H′3−−→ τ2 is derivable withC H1;H ′′2 v H ′1, so the result follows by an instance of

APP, Lemma 3.1 and Lemma 6.4, takingH2 = H ′′2 ;H ′2;H ′3. The other cases follow insimilar manner, caseE = vE′ with a little help from Corollary 6.1. ut

Page 25: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 25

Corollary 6.2. If Γ,C,H ` E[ev(c)] : τ is derivable, there existsH ′ such thatC ev(c);H ′ v H.

We also show that typing is preserved by contextual substitution:

Lemma 6.12 (Context Substitution).If Γ,C,H1;H2 ` E[e] : τ is derivable with asubderivation concluding inΓ,C,H1 ` e : τ ′ for e in the hole, andΓ,C,H ′1 ` e′ : τ ′

is derivable, then so isΓ,C,H ′1;H2 ` E[e′] : τ .

Proof. Straightforward by induction onE and Lemma 6.11.

Now, the main result for→ reduction:

Lemma 6.13 (Subject Reduction→). If Γ,C,H ` e : τ is derivable for closede andη, e→ η′, e′, thenΓ,C,H ′ ` e′ : τ is derivable withC η′;H ′ v η;H.

Proof. The following hold by assumption and definition of→:

e = E[e1] with e1 a redex e′ = E[e2] η, e1 η′, e2

Also, by Lemma 6.11 there exists a derivation ofΓ,C,H1;H2 ` e : τ with C H1;H2 v H, and with a subderivation concluding inΓ,C,H1 ` e1 : τ ′ for e1 in thehole. Furthermore, by Lemma 6.10 we have thatΓ,H ′1 ` e2 : τ ′ is derivable with:

C η′;H ′1 v η;H1

Now, the following judgement is derivable by Lemma 6.12:

Γ,C,H ′1;H2 ` E[e2] : τ

and by Lemma 3.1, Lemma 6.4, preceding facts, and Lemma 6.1:

C η;H1;H2 v η;HC η′;H ′1;H2 v η;H1;H2

C η′;H ′1;H2 v η;H

The result follows takingH ′ = H ′1;H2. ut

Note that as a corollary of this result, we may formalize the intuition that “trace effectspredict run-time program traces”:

Corollary 6.3 (Trace Approximation). If Γ,C,H ` e : τ is derivable for closedeandε, e→? η, e′ andC H v H ′ for closedH ′, thenη ∈ JH ′K.

Proof. By Lemma 6.13 and induction on the length of reduction there existsH ′′ suchthatΓ,C,H ′′ ` e′ : τ is derivable withC η;H ′′ v H. Now, supposeρ is a solutionof C, meaning thatJη; ρ(H ′′)K ⊆ Jρ(H)K, therefore clearlyη ∈ Jρ(H)K. Since alsoJρ(H)K ⊆ H ′, the result follows. ut

Using well-known strategy, we demonstrate progress on the basis of a canonicalforms lemma, establishing the form of values denoted by a particular type:

Page 26: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

26 Christian Skalka, Scott Smith, and David Van Horn

Lemma 6.14 (Canonical Forms).If Γ,C,H ` v : τ is satisfiable for closedv, thenthe following conditions hold:

i. If τ = bool thenv is eithertrue or false.ii. If τ = unit thenv = ().

iii. If there existss such thatτ = {s} then there existsc such thatv = c.

iv. If there existsτ1,H, τ2 such thatτ = τ1H−→ τ2 then eitherv is some function

λzx.e, or v is in {∧,∨,¬}.

Proof. Suppose thatτ = bool, and suppose on the contrary thatv 6∈ {true, false}. Thenby Lemma 6.8 and remaining possible forms ofv it is the case thatΓ,C, ε ` v : τ ′ such

thatC τ ′ v bool whereτ ′ is of the formunit, {c}, or τ1H−→ τ2. Lemma 6.2 implies

the contradiction. The other cases follow in a similar manner. ut

Finally, on the basis of the proceeding we can prove our main type safety results.

Theorem 6.1 (Progress).SupposeΓ,C,H ` e : τ is satisfiable, there exists a solutionρ ofC such thatρ(η;H) is valid, andη, e is irreducible. Thene is a value.

Proof. Suppose on the contrary thate is not a value. Then by definition of→, e is ofthe formE[f ], with Γ,C,H ′ ` f : τ ′ derivable as a subderivation ofΓ,C,H ` e : τ ,and where one of the following cases holds by definition of :

Case (f is one of{if v then e1 else e2,∧v,∨v,¬v}, wherev is not a boolean value).In this case it is easy to show by inversion of either IF or APP thatΓ,C,H ′′ ` v : bool.The contradiction follows by Lemma 6.14.

Case (f is ev(v) andv is not a singleton constantc). Similar to the previous case.Case (f is φ(c) whereΠ(φ(c), η evφ(c)) does not hold). By Corollary 6.2, there

existsH2 such thatC evφ(c);H2 v H. By assumption there exists a solutionρ ofC such thatρ(η;H) is valid, andJρ(η; evφ(c);H2)K ⊆ Jρ(η;H)K by Definition 5.3,henceρ(η; evφ(c);H2) is also valid by Lemma 3.2. But interpretations of effects areprefix-closed, so clearlyη evφ(c) ∈ Jρ(η; evφ(c);H2)K, soΠ(φ(c), η evφ(c)) holds byDefinition 3.4, which is a contradiction. ut

Theorem 6.2 (Type Safety).If Γ,C,H ` e : τ is valid for closede thene does not gowrong.

Proof. Suppose on the contrary thatε, e →n η, e′ with η, e′ irreducible ande′ not avalue. ThenΓ,C,H ′ ` e′ : τ is derivable withC η;H ′ v H by Lemma 6.13,induction onn, and Lemma 6.1. Now, sinceΓ,C,H ` e : τ is valid by assumption,therefore there exists a solutionρ of C such thatρ(H) is valid by Definition 6.4. ButsinceJρ(η;H ′)K ⊆ Jρ(H)K by Definition 5.3, thereforeρ(η;H ′) is valid by Lemma 3.2.The contradiction follows by Theorem 6.1. ut

7 Subtyping Constraint Inference

Like the HM style type system of Fig. 4, typings specified by the subtyping system ofFig. 9 are inferable. We now give a type inference algorithm for constraint subtyping,

Page 27: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 27

C-FN

(τ1H−→ τ2 v τ ′1

H′−−→ τ ′2) close (τ ′1 v τ1 ∧ τ2 v τ ′2 ∧H v H ′)

C-TRANS

(τ1 v τ2 ∧ τ2 v τ3) close τ1 v τ3

C-SINGLETON

{τ1} v {τ2} close τ1 v τ2

C-CONTEXTC′ ⊆ C C′ close D D 6⊆ C

C →close C ∧D

Fig. 12.Constraint closure rules

` true : ok` C : ok ` D : ok

` C ∧D : ok` H v H ′ : ok ` τ v τ : ok

τ, β : k

` τ v β : ok

τ, β : k

` β v τ : ok` τ1

H−→ τ2 v τ ′1H′−−→ τ ′2 : ok

` {τ1} v {τ2} : ok

Fig. 13.Constraint consistency rules

and prove that it is sound and complete with respect to logical judgements. Furthermore,our completeness result yields a principal types property forλtraceconstraint subtyping.The inference algorithm and form of judgements are the same as for the HM stylesystem, defined in Fig. 5. The difference is in the constraint solution technique. Ratherthan a unification-based solver as in in the HM style system, we use aclosuretechnique.The technique is standard, with extensions to accommodate trace effects and singletontypes. In order to exploit model checking techniques to verify inferred effects, we alsodevelop aneffect extractionalgorithm to represent top-level effects in term form. Ourtechnical development culminates in Corollary 7.1 and Lemma 7.22, formally estab-lishing correctness of the composition of inference, closure, and effect extraction, butbefore the proofs we provide some initial definitions and intuitions.

Closure and consistency.In contrast to unification, which literally generates a solutionto the constraint system, closure only verifies that a constraint is solvable. The closurealgorithm is the iteration of a single-step rewrite relation defined in Fig. 12. Each rewriterules makes explicit constraints that are implicit in existing ones– for example, observethat closure of a constraint{s1} v {s2} addss1 v s2 to the closure. When no newconstraints can be added, closure terminates. Formally:

Definition 7.1 (Constraint Closure).The rewrite relations close and→close are de-fined in Fig. 12.C is closediff there does not existD such thatC →close D. The

Page 28: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

28 Christian Skalka, Scott Smith, and David Van Horn

hextract C H = hextractC(H,∅)

hextractC(ε, hs) = ε

hextractC(ev(α), hs) = ev(boundsC α)

hextractC(h, hs) = h h ∈ hshextractC(h, hs) = µh.hextractC((boundsC h), hs ∪ {h}) h 6∈ hs

hextractC(H1;H2, hs) = (hextractC(H1, hs)); (hextractC(H2, hs))

hextractC(H1|H2, hs) = (hextractC(H1, hs))|(hextractC(H2, hs))

boundsC β = τ1| · · · |τn where{τ1, . . . , τn} = {τ | τ v β ∈ C andτ 6∈ Vk}

Fig. 14.hextract , hextractC , andbounds functions

relation→?close is the reflexive, transitive closure of→close . We defineclose(C) as a

closed constraint such thatC →?close close(C).

When closure terminates, all “atomic elements” of the constraint system are made ev-ident. A simple structural consistency check, defined in Fig. 13, can then be used toensure that all constraints entailed by the closure are solvable. For example, observethat clashing types in the sense of Lemma 6.2 cannot populate a consistent constraint.The definition of consistency exploits kinding rules extended to type terms to ensureconsistency of constraints involving variables. Formally:

Definition 7.2. A type termτ has kindk, written τ : k, iff the root constructor of anyinterpretation ofτ has kindk as specified in Fig. 11.

Note that sanity conditions on interpretations imply that ifβ ∈ Vk, thenβ : k.

Extracting effects from constraints.While demonstrating solvability is sufficient forconstraints in general, model checking of inferred trace effects requires that they be pre-sented in term form, not constraint form. Thus, we define another algorithm in Fig. 14,calledhextract , that extracts a term representation of the inferred top level trace effectfrom a given constraint. The algorithmhextract is defined in a curried style, that inte-grates nicely with a combinator fixpoint construction proof technique, used for provingsoundness ofhextract in Sect. 7.3. The definition ofhextractC specifies a family offunctions, each element of which has is defined in terms of a fixed parameterC. Notethat hextractC is not defined on theµ-bound form of trace effects, because this formdoes not occur in inferred types and constraints. However,hextractC does introduceµ-bindings, in order to solve recursively constrained effect variables.

Like the solution technique for the HM style system,hextract exploits the propertythat inferred constraints define a system of lower bounds on effect variables. However,in the subtyping constraint system, there is the added complication of singleton uniontypes, as presented in Definition 6.1– although it turns out that singleton constraintsalso define a system of lower bounds on variables. The functionboundsC obtains theset of lower bounds of a given variable inC.

Page 29: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 29

7.1 Soundness of Inference

Before delving into our main results, here are some auxiliary lemmas concerning vari-able freshness and constraint entailment that will be useful in later proofs.

Lemma 7.1. If Γ,H `β e : τ/C is canonically derivable, thenβ#fv(Γ ) and alsofv(τ, C,H) ⊆ fv(Γ ) ∪ β.

Lemma 7.2. All of the following properties hold:

1. If C τ ′ v τ , thenfv(τ) ⊆ fv(τ ′, C).2. C ∧D D.3. If C τ v τ ′ thenψ(C) ψ(τ) v ψ(τ ′).

We now demonstrate soundness of type inference with respect to constraint subtyping–that is, we show that inferred judgements are derivable in the logical constraint subtyp-ing system of Fig. 9. For this purpose it is necessary to convert constrained type schemesin inference environments to unconstrained type schemes in logical environments.

Definition 7.3. We define the following environment transformation function:

b∅c = ∅

bΓ ;x : ∀β.τ/Cc = bΓ c;x : ∀β.τ

Now, soundness can be proved by a straightforward induction on inference derivations.The proof technique essentially rewrites inference derivations into logical derivationsby pushing reconstructed constraints from the root to the leaves.

Lemma 7.3 (Soundness of Subtype Inference).If Γ,H `β e : τ/C is canonicallyderivable, then so isbΓ c, C ∧D,H ` e : τ for anyD.

Proof. By induction on the derivation ofΓ,H `β e : τ/C and case analysis on the lastrule instance.

Case VAR. In this casee = x andH = ε and τ/C = τ0[β/β0]/C0[β/β0] bydefinition of inference derivations, where:

Γ (x) = ∀β0.τ0/C0

Γ, ε `β x : τ0[β/β0]/C0[β/β0]

But since clearlyC0[β/β0] ∧D [β/β0] for arbitraryD, therefore by an instance ofVAR and an instance of∀-ELIM we can derive:

bΓ c(x) = ∀β0.τ0

bΓ c, C0[β/β0], ε ` x : ∀β0.τ0 C0[β/β0] [β/β0]bΓ c, C0[β/β0], ε ` x : τ0[β/β0]

Case LET. In this casee = letx = v in e0 andC = C1 ∧ C2 and β = β1β2 bydefinition of inference derivations, and we have:

β1#β2 Γ, ε `β1v : τ1/C1 Γ ;∀β1.τ1/C1, ε `β2

e0 : τ2/C2

Γ,H `β1β2letx = v in e0 : τ/C1 ∧ C2

Page 30: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

30 Christian Skalka, Scott Smith, and David Van Horn

But by the induction hypothesis both of:

bΓ c, C1 ∧ C2, ε ` v : τ1 bΓ c;x : ∀β1.τ1, C1 ∧ C2,H ` e0 : τ2

are derivable, and by Lemma 7.1 we have thatβ1#fv(Γ ), henceβ1#fv(bΓ c), so byapplications of∀-INTRO and LET:

bΓ c, C1 ∧ C2, ε ` v : τ1 β1#fv(bΓ c)bΓ c, C1 ∧ C2, ε ` v : ∀β1.τ1

bΓ c;x : ∀β1.τ1, C1 ∧ C2,H ` e0 : τ2bΓ c, C1 ∧ C2,H ` letx = v in e0 : τ2

Case FIX . In this case:

e = λzx.e′ β = β′ ∪ {t, h, t′} H = h τ = t

h−→ t′

C = C ′ ∧ τ ′ v t′ ∧H v h

where we have:

Γ ;x : t; z : t h−→ t′,H ′ `β e′ : τ ′/C

Γ, ε `β′∪{t,h,t′} λzx.e′ : t h−→ t′/C ′ ∧ τ ′ v t′ ∧H ′ v h

by definition of inference derivations. By the induction hypothesis, the judgement:

bΓ c;x : t; z : t h−→ t′, C,H ′ ` e′ : τ ′

is derivable, so by applications of SUB and FIX :

bΓ c;x : t; z : t h−→ t′, C,H ′ ` e′ : τ ′ C ′ τ ′ v t′ C ′ H ′ v h

bΓ c;x : t; z : t h−→ t′, C, h ` e′ : t′

bΓ c, C, ε ` λzx.e′ : t h−→ t′

Case EVENT. In this case we have:

e = ev(e′) H = H ′; ev(α) τ = unit C = C ′ ∧ τ ′ v {α} β = β′ ∪{α}

by definition of inference derivations, and as the last derivation step:

Γ,H ′ `β′ e′ : τ ′/C ′

Γ,H ′; ev(α) `β′∪{α} ev(e′) : unit/C ′ ∧ τ ′ v {α}

By the induction hypothesis, the judgementbΓ c, C,H ′ ` e′ : τ is derivable, and sinceC τ ′ v {α}, by instances of SUB and LET:

bΓ c, C,H ′ ` e′ : τ C τ ′ v {α}bΓ c, C,H ′ ` e′ : {α}

bΓ c, C,H ′; {α} ` ev(e′) : unit

Page 31: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 31

Case APP. In this case by definition of inference derivations we have:

e = e1e2 C = C1 ∧ C2 ∧ τ1 v τ2h−→ t H = H1;H2;h τ = t

β = β1β2 ∪ {t, h}

and as the last derivation step:

β1#β2 Γ,H1 `β1e1 : τ1/C1 Γ,H2 `β2

e2 : τ2/C2

Γ,H1;H2;h `β1β2∪{t,h} e1e2 : t/C1 ∧ C2 ∧ τ1 v τ2h−→ t

But by the induction hypothesis, both ofΓ,H1, C ` e1 : τ1 andΓ,H2, C ` e2 : τ2 are

derivable, and sinceC τ1 v τ2h−→ t by Lemma 7.2, we can derive by applications of

SUB and APP:

Γ,H1, C ` e1 : τ1 C τ1 v τ2h−→ t

Γ,H1, C ` e1 : τ2h−→ t Γ,H2, C ` e2 : τ2

Γ,H1;H2;h,C ` e1e2 : t

so this case holds.Case IF. In this case we have:

e = if e1 then e2 else e3 τ = t H = H1;H2|H3

C = C1 ∧ C2 ∧ C3 ∧ τ1 v bool∧ τ2 v t ∧ τ3 v t β = β1β2β3 ∪ {t}

by definition of inference derivations, where as the last derivation step:

β1#β2#β3

Γ,H1 `β1e1 : τ1/C1 Γ,H2 `β2

e2 : τ2/C2 Γ,H3 `β3e3 : τ3/C3

Γ,H1;H2|H3 `β if e1 then e2 else e3 : t/C

By the induction hypothesis, each of:

bΓ c, C,H1 ` e1 : τ1 bΓ c, C,H2 ` e2 : τ2 bΓ c, C,H3 ` e3 : τ3

is derivable, and by Lemma 7.2 and Lemma 6.4:

C H2 v H2|H3 C H3 v H3|H3 C τ1 v bool C τ2 v t

C τ3 v t

so by an application of SUB:

bΓ c, C,H1 ` e1 : τ1 C τ1 v bool

bΓ c, C,H1 ` e1 : bool

and also by an application of SUB:

bΓ c, C,H2 ` e2 : τ2 C H2 v H2|H3 C τ2 v tbΓ c, C,H2|H3 ` e2 : t

Page 32: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

32 Christian Skalka, Scott Smith, and David Van Horn

and by another application of SUB:

bΓ c, C,H3 ` e3 : τ3 C H3 v H2|H3 C τ3 v tbΓ c, C,H2|H3 ` e3 : t

so by an application of IF:

bΓ c, C,H1 ` e1 : bool bΓ c, C,H2|H3 ` e2 : t bΓ c, C,H2|H3 ` e3 : tbΓ c, C,H1;H2|H3 ` if e1 then e2 else e3 : t

So this case holds. Case CONST is immediate by nearly exact correspondence of theCONST rule forms in the logical and inference systems, so the result follows. ut

7.2 Completeness of Inference

As is usually the case, completeness is a more difficult manner than soundness, andthe development requires more formal overhead. To wit, we extend thev relation toconstrained types, to relate constrained type schemes (taken from logical judgements)with unconstrained type schemes (taken from inference judgements), and to relate con-strained type environments with unconstrained type environments. This is all with aview to relating the generality of type inference judgements with logical type judge-ments. The extendedv relation between type schemes also takes into account general-ization of type variables.

Definition 7.4. The relationv is extended to constrained types, type schemes, and typeenvironments as follows:

C C ′ C τ ′ v τ

τ ′/C ′ v τ/C

∀[τ /β] . C [τ /β]⇒ ∃[τ ′/β′] . (τ ′/C ′)[τ ′/β′] v (τ [τ /β]/C)C ∀β′.τ ′/C ′ v ∀β.τ

∀x ∈ dom(Γ ) . C Γ (x) v Γ ′(x)C Γ v Γ ′

Lemma 7.4. Definition 7.4 preserves reflexivity and transitivity ofv .

To formalize “maximum” generalization of type schemes, we define thegen func-tion, and to specify the generalizable variables in a judgement, we define thegenvarsfunction.

Definition 7.5. Definegen(Γ,C,∀β.τ) = ∀β′.τ whereβ = fv(τ, C) − fv(Γ ). Definegenvars(Γ,C,H, ∀β.τ) = fv(C,H, τ)− fv(Γ ).

Lemma 7.5. Given∀β.τ , andΓ such thatβ#fv(Γ ), thenC gen(Γ,C,∀β.τ) v∀β.τ for anyC. Further, for allσ andx such thatΓ (x) = σ, we havegen(Γ,C, σ) =σ.

Page 33: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 33

Note that in the second part of the above definition, while extraneous bindings inσmay be eliminated in its generalization, the equivalence still holds since we equate typeschemes up to elimination of extraneous variables in Sect. 4.

Next, we formalize the principality relation on type judgements, relating inferencejudgements with logical judgements. We will show that most general types are inferred,according to this relation. The relation is parameterized by a substitutionψ, that mayinstantiate free variables in inference judgements for relation to logical judgements; in-tuitively, ψ imposes the unnecessary assumptions made in type environments in logicalderivations.

Definition 7.6. Givengenvars(Γ,C,H,∀β0.τ) = β. The relation:

Γ ′,H ′ `β′ e : τ ′/C ′ vψ Γ,C,H ` e : ∀β0.τ

holds iffC ψ(Γ ′) v Γ , and for all ψ′′ = [τ /β] whereC [τ /β] there existsψ′ = [τ ′/β′] such that:

C ψ′ ◦ ψ(C ′) C ψ′ ◦ ψ(H ′) v ψ′′(H) C ψ′ ◦ ψ(τ ′) v ψ′′(τ)

The relationvψ takes into account generalizability of top-level effects, but for typ-ing of values, for which effects areε, it is simpler to speak in terms of maximal gener-alization of types alone. The next Lemmas establish relevant properties.

Lemma 7.6. Supposing thatdom(ψ) ⊆ fv(Γ ′) and:

Γ ′,H ′ `β′ e : τ ′/C ′ vψ Γ,C,H ` e : σ

ThenC ′ ∀β′.ψ(τ ′/C ′) v gen(Γ,C, σ), andH = ε impliesH ′ = ε.

Lemma 7.7. Givenψ and judgementsΓ,C, ε ` e : σ andΓ ′, ε `β′ e : τ ′/C ′ wheredom(ψ) ⊆ fv(Γ ′) andC ψ(Γ ′) v Γ . ThenC ∀β′.ψ(τ ′/C ′) v gen(Γ,C, σ)implies:

Γ ′, ε `β′ e : τ ′/C ′ vψ Γ,C, ε ` e : σ

Now, a few more auxiliary properties and definitions, including a definition of sub-stitution restriction, before the main completeness result, which follows by inductionon logical type derivations.

Lemma 7.8. If C τ1 v τ ′1 and for all ψ1 with C ψ1 there existsψ2 such thatC ψ2(τ2) v ψ1(τ1), thenC ψ2(τ2) v ψ1(τ ′1).

Proof. By Lemma 7.2 it is the case thatψ1(C) ψ1(τ1) v ψ1(τ ′1), soC ψ1(τ1) vψ1(τ ′1) by Lemma 6.4, thusC ψ2(τ2) v ψ1(τ ′1) by Lemma 6.4. ut

Definition 7.7. Given β ⊆ dom(ψ); write ψ |β to denoteψ′ such thatdom(ψ′) = β

andψ′(β) = ψ(β).

Lemma 7.9. For all β ⊆ dom(ψ), if C ψ thenC ψ |β .

Page 34: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

34 Christian Skalka, Scott Smith, and David Van Horn

Lemma 7.10 (Completeness of Subtype Inference).Givenψ,Γ ′, and derivable judge-mentΓ,C,H ` e : σ such thatC ψ(Γ ′) v Γ and dom(ψ) ⊆ fv(Γ ′). Then ajudgementΓ ′,H ′ `β′ e : τ ′/C ′ is canonically derivable, where:

Γ ′,H ′ `β′ e : τ ′/C ′ vψ Γ,C,H ` e : σ

Proof. By induction on the derivation ofΓ,C,H ` e : σ, and case analysis on the lastrule instance in the derivation.

Case VAR. In this case by definition of subtyping derivations,H = ε ande = x andwe can reconstruct:

Γ (x) = σ

Γ,C, ε ` x : σ

But by VAR in the inference system we can construct:

Γ ′(x) = ∀β′.τ ′/C ′

Γ ′, ε `β′′ x : τ ′[β′′/β′]/C ′[β′′/β′]

whereβ′′ are fresh by canonical form derivations. Since dom(ψ) = fv(Γ ′), observethat:

ψ(∀β′.τ ′/C ′) = ∀β′.ψ(τ ′/C ′)

Now, lettingσ = ∀β.τ , take some arbitrary[τ /β] such thatC [τ /β]; then we haveby assumption and Definition 7.4:

∃[τ ′/β′] . (ψ(τ ′/C ′))[τ ′/β′] v (τ [τ /β]/C)

Let:

τ ′′ = τ ′[β′′/β′] C ′′ = C ′[β′′/β′]

Sinceβ′′ are fresh, thereforeβ′#β′′#dom(ψ), hence:

(ψ(τ ′′/C ′′))[τ ′/β′′] = (ψ(τ ′/C ′))[τ ′/β′]

so:(ψ(τ ′′/C ′′))[τ ′/β′′] v (τ [τ /β]/C)

Since∀β.τ = gen(Γ,C, σ) by Lemma 7.5, the result follows by Definition 7.4 andLemma 7.7.

Case LET. In this casee = letx = v in e′ andσ = τ and by definition of subtypingderivations we can reconstruct:

Γ,C, ε ` v : σ′ Γ ;x : σ′, C,H ` e′ : τΓ,C,H ` letx = v in e′ : τ

By the induction hypothesis , a judgementΓ ′, ε `β1v : τ1/C1 is canonically derivable,

where there existsψ1 = [τ1/β1] such that:

C ψ1 ◦ ψ(C1)

Page 35: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 35

and by Lemma 7.6:

C ∀β1.ψ(τ1/C1) v gen(Γ,C, σ′)

But dom(ψ)#β1 by Lemma 7.1, hence:

∀β1.ψ(τ1/C1) = ψ(∀β1.τ1/C1)

so by Lemma 7.4 and Lemma 7.5:

C ψ(∀β1.τ1/C1) v σ′

Thus,C ψ(Γ ′;x : ∀β1.τ1/C1) v Γ ;x : σ by Definition 7.4. By Lemma 7.1 and theinduction hypothesis, lettingβ = genvars(Γ,C,H, τ) we have that:

Γ ′;x : ∀β1.τ1/C1,H2 `β2e′ : τ2/C2

is canonically derivable, where there existsψ2 with dom(ψ2) = [τ2/β2] such that forarbitraryψ′′ = [τ /β] with C [τ /β]:

C ψ2 ◦ ψ(C2) C ψ2 ◦ ψ(τ2) v ψ′′(τ) C ψ2 ◦ ψ(H2) v ψ′′(H)

Assumeβ2#β1 wlog, so that as an instance of LET:

Γ ′, ε `β1v : τ1/C1 Γ ′;x : ∀β1.τ1/C1,H2 `β2

e′ : τ2/C2

Γ ′,H2 `β1β2letx = v in e′ : τ2/C1 ∧ C2

Now, we have by assumption and Lemma 7.1 thatβ2#β1#fv(Γ ), and also by Lemma 7.1:

fv(τ1, C1) ⊆ fv(Γ ) ∪ β1 fv(τ2, C2,H2) ⊆ fv(Γ ) ∪ β2

so clearly:

ψ1 ◦ ψ(C1) = ψ1 ◦ ψ2 ◦ ψ(C1) ψ2 ◦ ψ(C2) = ψ1 ◦ ψ2 ◦ ψ(C2)

ψ2 ◦ ψ(τ2) = ψ1 ◦ ψ2 ◦ ψ(τ2) ψ2 ◦ ψ(H2) = ψ1 ◦ ψ2 ◦ ψ(H2)

therefore by the above:

C ψ1 ◦ ψ2 ◦ ψ(C1 ∧ C2) C ψ1 ◦ ψ2 ◦ ψ(τ2) v ψ′′(τ)

C ψ1 ◦ ψ2 ◦ ψ(H2) v ψ′′(H)

and dom(ψ1 ◦ ψ2) = β1β2, so this case holds by Definition 7.6.Case∀-INTRO. In this case by definition of subtyping derivations we have thate = v

andσ = ∀β.τ , and we can reconstruct:

Γ,C, ε ` v : τ β#fv(Γ )Γ,C, ε ` v : ∀β.τ

Page 36: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

36 Christian Skalka, Scott Smith, and David Van Horn

By the induction hypothesis and Lemma 7.6 there exists derivableΓ ′, ε `β′ v : τ ′/C ′,withC ∀β′.ψ(τ ′/C ′) v gen(Γ,C, τ). ButC gen(Γ,C, τ) v ∀β.τ by Lemma 7.5,therefore by Lemma 7.4 we haveC ∀β′.ψ(τ ′/C ′) v ∀β.τ , so this case holds byLemma 7.7.

Case∀-ELIM . In this case by definition of subtyping derivations we have thate = vandσ = τ [τ /β], and we can reconstruct:

Γ,C, ε ` v : ∀β.τ C [τ /β]Γ,C, ε ` v : τ [τ /β]

By the induction hypothesis and Lemma 7.6 there exists derivableΓ ′, ε `β′ v : τ ′/C ′,with C ∀β′.ψ(τ ′/C ′) v gen(Γ,C,∀β.τ). Let ∀β0.τ = gen(Γ,C,∀β.τ) andβ1 ={β|β ∈ β0 − β

}. Then τ [τ /β] = τ [τ /β][β1/β1]. Let ψ0 = [τ /β][β1/β1] and let

gen(Γ,C, τ [τ /β]) = ∀β2.τ [τ /β]. It is easy to show thatβ2 ⊆ β1 ∪ fv(τ); hence forarbitrary[τ2/β2] such thatC [τ2/β2], we have dom([τ2/β2] ◦ ψ0) ⊆ β0, hence thereexistsτ3 such that[τ3/β0] = [τ2/β2] ◦ψ0. Thus by Definition 7.4 and above facts thereexists[τ ′/β′] such that the following entailments hold:

C (ψ(C ′))[τ ′/β′] C (ψ(τ ′))[τ ′/β′] v τ [τ3/β0]

the latter of which is to say by the above equivalences:

C (ψ(τ ′))[τ ′/β′] v (τ [τ /β])[τ2/β2]

so this case holds by Definition 7.4 and Lemma 7.7.Case EVENT. In this casee = ev(e0) andσ = unit andH = H0; ev(s) by definition

of subtyping derivations, where we can reconstruct the following rule instance:

Γ,C,H0 ` e0 : {s}Γ,C,H0; ev(s) ` ev(e0) : unit

Let genvars(Γ,C,H0, {s}) = β. Then by the induction hypothesis there exists deriv-ableΓ ′,H ′ `β′ ev(e0) : τ ′/C ′, where for allψ0 = [τ /β] such thatC [τ /β] thereexistsψ′ = [τ ′/β′] such that:

C ψ′ ◦ ψ(C ′) C ψ′ ◦ ψ(τ ′) v ψ0({s}) C ψ′ ◦ ψ(H ′) v ψ0(H0)

and by an instance of EVENT we can canonically infer:

Γ ′,H ′ `β′ ev(e0) : τ ′/C ′

Γ ′,H ′; ev(α) `β′∪{α} ev(e′) : unit/C ′ ∧ τ ′ v {α}

Now, sinceα is canonically chosen fresh, by Lemma 7.1α#β′#dom(ψ) and:

fv(τ ′, C ′,H ′) ⊆ dom(ψ) ∪ β′

Therefore lettingψ′′ = ψ′ ◦ [ψ0(s)/α]:

ψ′′ ◦ ψ(α) = ψ0(s) ψ′′ ◦ ψ(C ′) = ψ′ ◦ ψ(C ′) ψ′′ ◦ ψ(τ ′) = ψ′ ◦ ψ(τ ′)

ψ′′ ◦ ψ(H ′) = ψ′ ◦ ψ(H ′)

Page 37: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 37

so by the above facts and Lemma 6.4:

C ψ′′ ◦ ψ(C ′ ∧ τ ′ v {α}) C ψ′′ ◦ ψ(H ′; ev(α)) v ψ0(H0; ev(s))

and dom(ψ′′) = β′ ∪ {α}, so this case holds by Definition 7.6.

Case FIX . In this case we havee = λzx.e′ andH = ε andτ = τ1

H′−−→ τ2 bydefinition of subtyping derivations, with the following as the last derivation step:

Γ ;x : τ1; z : τ1H1−−→ τ2, C,H1 ` e′ : τ2

Γ,C, ε ` λzx.e′ : τ1H1−−→ τ2

Letψ0 = [τ1/t1][τ2/t2][H1/h] ◦ψ. Sincet1, t2, h are chosen fresh in canonical deriva-

tions, thereforeC ψ0(t1h−→ t2) v τ1

H1−−→ τ2 and by Definition 7.4:

C ψ0(Γ ′;x : t1; z : t1h−→ t2) v (Γ ;x : τ1; z : τ1

H1−−→ τ2)

Therefore, sincegenvars(Γ ;x : τ1; z : τ1H1−−→ τ2, C,H1, τ2) = ∅, by the induction

hypothesis a judgement of the following form is derivable:

Γ ′;x : t1; z : t1h−→ t2,H

′ `β′′ e′ : τ ′/C ′

where there existsψ′ = [τ /β′′] such that:

C ψ′ ◦ ψ0(C ′) C ψ′ ◦ ψ0(H ′) v H1 C ψ′ ◦ ψ0(τ ′) v τ2

But lettingψ′′ = ψ′ ◦ [τ1/t1][τ2/t2][H1/h], equivalently:

C ψ′′ ◦ ψ(C ′) C ψ′′ ◦ ψ(H ′) v H1 C ψ′′ ◦ ψ(τ ′) v τ2

And freshness of{t1, t2, h}means{t1, t2, h}#β′′#dom(ψ), thereforeψ′′◦ψ(t1) = τ1andψ′′ ◦ ψ(t2) = τ2 andψ′′ ◦ ψ(h1) = H1, thus:

C ψ′′ ◦ ψ(C ′ ∧H ′ v h ∧ τ ′ v t2) C ψ′′ ◦ ψ(t1h−→ t2) v τ1

H1−−→ τ2

and dom(ψ′) = β′′ ∪ {t1, t2, h}. By an application of FIX :

Γ ′;x : t1; z : t1h−→ t2,H

′ `β′′ e′ : τ ′/C ′

Γ ′, ε `β′′∪{t1,t2,h} λzx.e′ : t1

h−→ t2/C′ ∧H ′ v h ∧ τ ′ v t2

so this case holds by Definition 7.6.Case APP. In this casee = e1e2 andH = H1;H2;H3 by definition of subtyping

derivations, and as the last step in the derivation:

Γ,C,H1 ` e1 : τ ′ H3−−→ τ Γ,C,H2 ` e2 : τ ′

Γ,C,H1;H2;H3 ` e1e2 : τ

Page 38: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

38 Christian Skalka, Scott Smith, and David Van Horn

Let:

genvars(Γ,C,H1, τ′ H3−−→ τ) = β genvars(Γ,C,H2, τ

′) = β′

genvars(Γ,C,H1;H2;H3, τ) = β′′

Letψ′ be an arbitrary substitution such that dom(ψ′) = ββ′ andC ψ′, and let:

ψβ = ψ′ |β ψβ′ = ψ′ |β′ ψβ′′ = ψ′ |β′′

Then by Lemma 7.9 and the induction hypothesis there exists a canonically derivablejudgementΓ ′,H ′1 `β1

e1 : τ1/C1 and substitutionψ1 = [τ1/β1] such that:

C ψ1 ◦ψ(C1) C ψ1 ◦ψ(τ1) v ψβ(τ ′ H3−−→ τ) C ψ1 ◦ψ(H ′1) v ψβ(H1)

Also by Lemma 7.9 and the induction hypothesis there exists canonically derivableΓ ′,H ′2 `β2

e2 : τ2/C2 and substitutionψ2 = [τ2/β2] such that:

C ψ2 ◦ ψ(C2) C ψ2 ◦ ψ(τ2) v ψβ′(τ ′) C ψ2 ◦ ψ(H ′2) v ψβ′(H2)

Note that:

ψβ(H1) = ψβ′′(H1) ψβ′(H2) = ψβ′′(H2) ψβ(H3) = ψβ′′(H3)

ψβ(τ) = ψβ′′(τ) ψβ(τ ′) = ψβ′(τ′)

Now, letψ3 = ψ2 ◦ [ψβ′′(τ)/t][ψβ′′(H3)/h]. Takingβ1#β2 wlog, by Lemma 7.1 it isthe case thatβ1#β2#dom(ψ) and:

fv(τ1,H ′1, C1) = fv(Γ ) ∪ β1 fv(τ2,H ′2, C2) = fv(Γ ) ∪ β2

therefore:

ψ3 ◦ ψ(τ1) = ψ1 ◦ ψ(τ1) ψ3 ◦ ψ(H1) = ψ1 ◦ ψ(H1)

ψ3 ◦ ψ(C1) = ψ1 ◦ ψ(C1) ψ3 ◦ ψ(τ2) = ψ2 ◦ ψ(τ2)

ψ3 ◦ ψ(H2) = ψ2 ◦ ψ(H2) ψ3 ◦ ψ(t) = ψβ′′(τ) ψ3 ◦ ψ(h) = ψβ′′(H3)

Combining these equivalences with preceding facts and Lemma 6.4, we have:

C ψ3 ◦ ψ(H ′1;H ′2;h) v ψβ′′(H1;H2;H3) C ψ3 ◦ ψ(t) v ψβ′′(τ)

We can also assert:

C ψ3 ◦ ψ(C1 ∧ C2) C ψβ(τ ′ H3−−→ τ) v ψ3 ◦ ψ(τ2h−→ t)

C ψ3 ◦ ψ(τ1) v ψβ(τ ′ H3−−→ τ)

Page 39: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 39

so by transitivity ofv, etc., we have:

C ψ3 ◦ ψ(C1 ∧ C2 ∧ τ1 v τ2h−→ t)

Finally, by APPwe can derive:

Γ ′,H ′1 `β1e1 : τ1/C1 Γ ′,H ′2 `β2

e2 : τ2/C2

Γ ′,H ′1;H ′2;h `β1β2{t,h} e1e2 : t/C1 ∧ C2 ∧ τ1 v τ2h−→ t

and since dom(ψ3) = β1β2 {t, h}, this case holds.Case IF. In this casee = if e1 then e2 else e3, andH = H1;H2, and as the last step

in the derivation:

Γ,C,H1 ` e1 : bool Γ,C,H2 ` e2 : τ Γ,C,H2 ` e3 : τΓ,C,H1;H2 ` if e1 then e2 else e3 : τ

Let:

genvars(Γ,C,H1,bool) = β genvars(Γ,C,H2, τ) = β′

and taking arbitrary dom(ψ′) = ββ′ such thatC ψ′, defineψβ = ψ′ |β andψβ′ = ψ′ |β′ . Then by Lemma 7.9 and the induction hypothesis, there exist derivablejudgements:

Γ ′,H ′1 `β1e1 : τ1/C1 Γ ′,H ′2 `β2

e2 : τ2/C2 Γ ′,H ′3 `β3e3 : τ3/C3

and substitutionsψ1, ψ2, ψ3 with dom(ψ1) = β1, dom(ψ2) = β2, dom(ψ3) = β3 suchthat:

C ψ1 ◦ ψ(C1) C ψ1 ◦ ψ(H ′1) v ψβ(H1) C ψ1 ◦ ψ(τ1) v ψβ(bool)

C ψ2 ◦ ψ(C2) C ψ2 ◦ ψ(H ′2) v ψβ′(H2) C ψ2 ◦ ψ(τ2) v ψβ′(τ)

C ψ3 ◦ ψ(C3) C ψ3 ◦ ψ(H ′3) v ψβ′(H2) C ψ3 ◦ ψ(τ3) v ψβ′(τ)

Assumeβ1#β2#β3 wlog. Note the following equivalences:

ψβ(bool) = bool ψβ′(τ) = ψ′(τ) ψβ(H1) = ψ′(H1) ψβ′(H2) = ψ′(H2)

and letψ4 = ψ1 ◦ ψ2 ◦ ψ3 ◦ [τ/t]. Then sinceβ1#β2#β3#t#dom(ψ) by assumption,canonical freshness oft, and Lemma 7.1, we haveψ4(t) = τ , and for alli ∈ [1..3]:

ψi ◦ ψ(Ci) = ψ4 ◦ ψ(Ci) ψi ◦ ψ(H ′i) = ψ4 ◦ ψ(H ′i) ψi ◦ ψ(τi) = ψ4 ◦ ψ(τi)

By the above facts and equivalences and Lemma 6.4 we can then assert:

C ψ4 ◦ ψ(t) v ψ′(τ) C ψ4 ◦ ψ(H ′1;H ′2|H ′3) v ψ′(H1;H2)

C ψ4 ◦ ψ(τ1) v bool C ψ4 ◦ ψ(τ2 v t) C ψ4 ◦ ψ(τ3 v t)

C ψ4 ◦ ψ(C1 ∧ C2 ∧ C3)

Page 40: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

40 Christian Skalka, Scott Smith, and David Van Horn

and lettingC ′ = C1∧C2∧C3∧ τ1 v bool∧ τ2 v t∧ τ3 v t, observeC ψ4 ◦ψ(C ′),and by IF we can derive:

β1#β2#β3 β4 = β1β2β3 ∪ {t}Γ ′,H ′1 `β1

e1 : τ1/C1 Γ ′,H ′2 `β2e2 : τ2/C2 Γ ′,H ′3 `β3

e3 : τ3/C3

Γ ′,H ′1;H ′2|H ′3 `β4if e1 then e2 else e3 : t/C ′

Therefore since dom(ψ4) = β1β2β3 ∪ {t}, this case holds.Case SUB. In this case by definition of subtyping derivations, we have as the last

step in the derivation:

Γ,C,H ′ ` e : τ ′ C τ ′ v τ C H ′ v HΓ,C,H ` e : τ

Letting genvars(Γ,C,H ′, τ ′) = β and taking arbitraryψ′ such that dom(ψ′) = β andC ψ′, by the induction hypothesis there exists derivableΓ ′, C0 `β0

e : τ0/C0 andsubstitutionψ0 such that:

C ψ0 ◦ ψ(C0) C ψ0 ◦ ψ(H0) v ψ′(H ′) C ψ0 ◦ ψ(τ0) v ψ′(τ ′)

But by Lemma 7.8 we have:

C ψ0 ◦ ψ(H0) v ψ′(H) C ψ0 ◦ ψ(τ0) v ψ′(τ)

and sincegenvars(Γ,C,H, τ) = genvars(Γ,C,H, τ) by Lemma 7.2, this case holds.Case CONST follows trivially, so the result follows. ut

7.3 Closure, Consistency, andhextract ion

Now we prove correctness of the closure, consistency, and effect extraction techniques.Since our closure and consistency algorithms are standard with respect to type con-straints, we mainly appeal to existing results, especially those in [27], to establish cor-rectness in that regard. The focus of our proof development is on satisfaction of single-ton and effect constraints, and extraction of effect terms from constraints viahextract .In fact, correctness ofhextract provides a constructive proof of the satisfiability ofclosed, consistent effect constraints.

We begin by observing that closure does not change the meaning of constraints,i.e. a constraint is logically equivalent to its closure:

Lemma 7.11. C = close(C).

One benefit of closure is that it provides a way to split constraints into distinct type,effect, and singleton components, the solutions for which can be composed to solve theentire constraint. We formalize this with the following definition and Lemma, wheref |S denotes the restriction of the domain of a functionf to S as usual.

Definition 7.8. For each kindk, thek componentof a constraintC is a constraintDsuch that:

set(D) = {τ1 v τ2 | τ1 v τ2 ∈ C andτ1, τ2 : k}Given thatD is thek component ofC, the constraintC has ak solutioniff there existsρ such thatρ D.

Page 41: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 41

Lemma 7.12. SupposeC is closed, andρ1, ρ2, andρ3 are Type, Sing, and Eff solutionsofC, respectively. Then:

(ρ1 |VType) ◦ (ρ2 |VSing) ◦ (ρ3 |VEff) C

The following Lemma establishes the crucial property that effect and singleton con-straints form a system of lower bounds on variables. This property implies that anyconsistent closure has a singleton and effect solution. It also suggests a technique forderiving term representations of singletons and effects, by joining lower bounds of vari-ables. This is not just convenient, but demonstrates that while effect constraint solutionis not decidable in general, it is so for the restricted form generated by inference.

Lemma 7.13. Suppose∅,H `β e : τ/C is derivable andτ1 v τ2 ∈ close(C). Ifτ2 : Sing thenτ2 is a singleton variableα, and ifτ2 : Eff thenτ2 is an effect variableh.

Now, we show that the singleton component of a closed, consistent constraint has asolution, that can be obtained via theboundsC function.

Definition 7.9. Supposef is a partial mapping from type variables to types. Writef 4 ρ iff there existsρ′ such thatρ = ρ′ ◦ f .

Lemma 7.14. Suppose∅,H `β e : τ/C is derivable andclose(C) is consistent. Thenthere exists a Sing solutionρ of close(C) such thatboundsclose(C) |VSing4 ρ.

Next, we show that the effect component of a closed, consistent constraint has asolution, that can be obtained via thehextract function. We show that this is the caseconstructively, by demonstrating thathextract is defined on top-level effects, and thathextract is a solution of given constraints. The first step is to show that top-level effectshave concrete lower bounds, so that their term form is closed.

Definition 7.10. LetC be closed and consistent. Thenτ1 is a component ofτ2 in C iffτ1 is a subterm ofτ2, or there exists a subtermτ ′1 of τ1 such thatτ ′2 v τ ′1 ∈ C andτ2 isa component ofτ ′2 in C.

Definition 7.11. LetC be closed and consistent. Then theabstract components ofτ inC, denotedabstract(τ, C) are the variable components ofτ that have no lower boundin C. More precisely:

abstract(τ, C) = {β | β is a component ofτ in C ∧ ¬∃τ ′.τ ′ v β ∈ C}

On the basis of these definitions, we can now show that top-level effects have con-crete lower bounds in inferred constraints, meaning thathextract is defined and closedon top-level effects The result follows by a tedious and unilluminating induction onderivations. Essentially, the property holds because any effect variable occurring in atop-level effect is the upper bound of a function effect by definition of inference, andsince top-level expressions are closed, the function must be a closed lambda abstraction,which have defined, concrete effects.

Lemma 7.15 (Top-level effects are concrete).Suppose∅,H `β e : τ/C is derivableandclose(C) is consistent. ThenH has no abstract components inclose(C).

Page 42: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

42 Christian Skalka, Scott Smith, and David Van Horn

HX f C ε = ε

HX f C ev(α) = ev(boundsC α)

HX f C h = f C (boundsC h) if boundsC h defined

HX f C h = f C h if boundsC h not defined

HX f C H1;H2 = (f C H1); (f C H2)

HX f C H1|H2 = (f C H1)|(f C H2)

Fig. 15.TheHX combinator

Lemma 7.16. Suppose∅,H `β e : τ/C is derivable andclose(C) is consistent. Then(hextract close(C) H) is defined and closed.

Having established thathextract is defined on top-level effects, we now show thathextract is a solution of given constraints. The recursive definition ofhextract makes adirect proof of this property difficult. Instead, we demonstrate the property via a combi-nator fixpoint construction. We define a non-recursive combinatorHX in Fig. 15, thatcharacterizes the solution of closed, consistent effect constraints, and then show thathextract is a fixpoint of this combinator. The first step is to show thatHX correctlycharacterizes solutions of closed, consistent effect constraints, as follows.

Lemma 7.17. Suppose∅,H `β e : τ/C is derivable andclose(C) is consistent.If f is a fixpoint ofHX , then there exists an Eff solutionρ of close(C) such that(f close(C)) 4 ρ.

Proof. Let D be theEff component ofclose(C), and suppose thatf is a fixpoint ofHX . Let ρ′ be aSingsolution ofclose(C), which must exist by Lemma 7.14, and let:

g = ρ′ ◦ (f close(C))

To proceed, we number the clauses ofHX from top to bottom, starting with 1. Since weassume thatf is a fixpoint ofHX , clauses 1-2 and 5-6 establish the following equalities:

g(ε) = ε g(ev(α)) = ρ′(ev(boundsC α)) g(H1;H2) = g(H1); g(H2)

g(H1|H2) = g(H1)|g(H1)

Thus,g is an interpretation, as defined in Fig. 6. Furthermore, clause 3 establishes thatfor all H v h ∈ D, it is the case thatg(H) 4 g(h), meaning thatg satisfies everyconstraint inD by Lemma 7.13, and is therefore a solution ofD. Letting ρ = g, theresult follows by Definition 7.9. ut

It would now be possible to show that any closed, consistent effect constraint has asolution, by showing thatHX is monotonic over a partial ordering of solutions, sinceclassic results in [41] would then imply thatHX has a fixpoint. Instead, we prove thathextract is a fixpoint ofHX in Lemma 7.17, establishing both correctness ofhextract

Page 43: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 43

and existence of a solution of closed consistent effect constraints. We first prove theessential auxiliary Lemma for proving the trickyµ case of Lemma 7.17, and thenLemma 7.17 itself.

Lemma 7.18. Leth 6∈ hs andH ′ = hextractC(h, hs). Then:

hextractC(H,hs ∪ {h})[H ′/h] = hextractC(H,hs)

Proof. The proof proceeds by induction on the call tree ofhextractC and case analysison H. In caseH = ε or H = ev(α) the result is immediate. In caseH = H1|H2

orH1;H2 the result follows in a straightforward manner via the induction hypothesis.The more interesting case is that in whichH is an effect variableh′. Here we considersubcasesh′ 6= h andh′ = h, where the former breaks down into subcases withh′ ∈ hson the one hand andh′ 6∈ hs on the other. Ifh′ 6= h andh′ ∈ hs, then by definition ofhextractC :

hextractC(h′, hs ∪ {h})[H ′/h] = hextractC(h′, hs) = h′

so the result follows.On the other hand, ifh′ 6= h andh′ 6∈ hs, then by definition ofhextractC :

hextractC(h′, hs∪{h})[H ′/h] = (µh′.hextractC((boundsC h′), hs∪{h, h′}))[H ′/h]

and:hextractC(h′, hs) = µh′.hextractC((boundsC h′), hs ∪ {h′})

LetH ′′ = hextractC((boundsC h′), hs ∪ {h, h′}). Sinceh′ 6= h by assumption:

(µh′.H ′′)[H ′/h] = µh′.(H ′′[H ′/h])

and by the induction hypothesis:

hextractC((boundsC h′), hs ∪ {h′}) = H ′′[H ′/h]

Hence:

hextractC(h′, hs ∪ {h})[H ′/h] = hextractC(h′, hs) = µh′.(H ′′[H ′/h])

so the result follows.Now, consider the subcaseh′ = h. Then by the definition ofhextractC :

hextractC(h, hs ∪ {h}) = h

and clearly:hextractC(h, hs ∪ {h})[H ′/h] = H ′

andhextractC(H,hs) = H ′ in this case, so the result follows. ut

Lemma 7.19. hextract is a fixpoint ofHX .

Page 44: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

44 Christian Skalka, Scott Smith, and David Van Horn

Proof. We begin by noting the obvious pointhextract C H = hextractC(H,∅). Toprove the result, it suffices to show that for allC and for allH in the domain ofHX f Cwe have:

HX hextract C H = hextract C H

The proof proceeds by case analysis onH.CaseH = ε. By definition ofHX andhextract :

HX hextract C ε = hextract C ε = ε

so this case holds.CaseH = ev(α). By definition ofHX andhextract :

HX hextract C ev(α) = hextract C ev(α) = ev(boundsC α)

so this case holds.CaseH = (H1|H2). By definition ofHX :

HX hextract C (H1|H2) = (hextract C H1)|(hextract C H2)

and by definition ofhextract :

hextract C (H1|H2, C) = hextract(H1, C)|hextract(H2, C)

so this case holds. CaseH = H1;H2 follows similarly.CaseH = h. By definition ofHX :

HX hextract C h = hextract C (boundsC h)

and by definition ofhextract :

hextract C h = hextractC(h,∅) = µh.hextractC((boundsC h), {h})

Now, letH ′ = µh.hextractC(boundsC(h), {h}). By Lemma 7.18 we have:

hextractC((boundsC h),∅) = (hextractC(boundsC(h), {h}))[H ′/h]

and by properties of trace effect equivalence noted in Lemma 3.1:

ρ((hextractC((boundsC h), {h}))[H ′/h]) = ρ(H ′)

so the result follows in this case, which was the last to be proven. ut

Having shown thathextract is a fixpoint ofHX , we can immediately demonstratethathextract implements a solution of given constraints when applied to top-level ef-fects.

Lemma 7.20 (Correctness ofhextract). Suppose∅,H `β e : τ/C is derivable andclose(C) is consistent. ThenC has an Eff solutionρ such that(hextract close(C)) 4 ρ.

Page 45: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 45

Proof. By Lemma 7.19,hextract is a fixpoint ofHX . The result follows immediatelyby Lemma 7.17. ut

Composition of the above Lemmas establishing solvability of singleton and effectconstraints, with standard results for closure and consistency of type constraints, allowsus to obtain that consistency of closure is equivalent to satisfiability.

Lemma 7.21 (Correctness of Closure).If ∅,H `β e : τ/C is derivable, thenC hasa solution iffclose(C) is consistent.

Proof. That solvability ofC entails consistency ofC follows via reductio ad absur-dum, since if we assume on the contrary thatclose(C) is inconsistent, this implies thatclose(C) contains a clashing constraint and thus the contradiction by Lemma 6.2. Theother direction proceeds as follows. By Lemma 7.14, there exists aSing solution ofclose(C). By Lemma 7.20, there exists anEff solution ofclose(C). Given this, we canshow thatclose(C) has aTypesolution by appeal to standard results, particularly thosein [27], since our closure and consistency techniques forTypeconstraints are standard.The result follows by Lemma 7.12 and Lemma 7.11. ut

Finally, we can tie all the results together to state high-level properties of the system.Since we have demonstrated completeness of inference in Lemma 7.10 and have shownthat consistent closure is equivalent to satisfiability in Lemma 7.21, we immediatelyobtain a completeness result for inference.

Corollary 7.1 (Implementation Completeness).If a closed expressione is typable inthe system of Fig. 9, then a judgement∅,H `β e : τ/C is derivable andclose(C) isconsistent.

However, since we have only shown thathextract is a fixpoint ofHX , not theleastfixpoint, the best we can demonstrate for the algorithm is soundness. We informallyconjecture thathextract implements a least solution of the given constraint, since itadds no extraneous constraints in the construction, but in any case soundness is suffi-cient to obtain a type safety result for the implementation, as follows.

Lemma 7.22 (Implementation Soundness).Suppose∅,H `β e : τ/C is derivableand close(C) is consistent. Then∅,H,C ` e : τ is satisfiable, and there exists asolutionρ ofC such that(hextract close(C) H) = ρ(H).

Proof. If ∅,H `β e : τ/C is derivable then so is∅,H,C ` e : τ by Lemma 7.3. Ifclose(C) is consistent thenC has a solutionρ′ by Lemma 7.21, and by Lemma 7.20Chas anEff solutionρ′′ such that(hextract close(C)) 4 ρ′′. Let ρ = ρ′ ◦ ρ′′ |VEff. Since(hextract close(C) H) is defined and closed by Lemma 7.16, therefore:

ρ′′(H) = (hextract close(C) H) = ρ(H)

andρ is a solution ofC by Lemma 7.12. ut

Page 46: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

46 Christian Skalka, Scott Smith, and David Van Horn

S ::= nil | S ::η history stacks

S, (λzx.e)v S ::ε, ·e[v/x][λzx.e/z]· (β)

S ::η, ev(c) S ::η; ev(c), () (event)

S ::η, evφ(c) S ::η; evφ(c), () (check)

if Π(φ(c), (S ::η)evφ(c))

S ::η, ·v· S, v (pop)

Fig. 16.Semantics ofλStrace (selected rules)

8 The Stack-Based Variation

In this section we define a stack-based variation on the framework of the previoussections, allowing properties of the runtime stack at a program point to be verified atcompile-time. Instead of keeping track ofall events, only events for functions on thecurrent call stack are maintained, in keeping with a general stack-based security model(as in e.g. [21]). Assertionsφ in this framework are run-time assertions about theac-tive event sequence, not all events. While the stack-based model is somewhat distinctfrom the trace-based model, we show that this variation requires only a minor “post-processing” of inferred trace effects for a sound analysis. There are results showinghow it is possible to directly model-check stack properties of a Push-Down Automata(PDA) computation [17]; our approach based on post-processing trace effects repre-sents an alternative method, which may also prove useful for modeling features such asexceptions: the raising of an exception implies any subsequent effect is discarded.

We note that our system captures a more fine-grained stack-based model than hasbeen previously proposed; in particular, the use of stacks of traces allows the ordering ofevents within individual stack frames to be taken into account, along with the orderingof frames themselves.

8.1 Syntax and Semantics

The values, expressions, and evaluation contexts ofλStraceare exactly those ofλtrace, ex-tended with an expression form·e· and evaluation context form·E· for delimiting thescope of function activations. We impose the requirement that in any functionλzx.e,there exist no subexpressions·e′· of e. The operational semantics ofλStrace, is a relationon configurationsS, e, whereS ranges over stacks of traces, defined in Fig. 16. Theactive security context for run-time checks is obtained from the trace stack in configu-rations, by appending traces in the order they appear in the stack. To formalize this, wedefine the notationbSc inductively as follows:

bnilc = ε bS ::ηc = bSc; η

Abusing notation, we writeS as syntactic sugar forbSc.

Page 47: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 47

stackify(ε) = ε

stackify(ε;H) = stackify(H)

stackify(ev(c);H) = ev(c); stackify(H)

stackify(h;H) = h|stackify(H)

stackify((µh.H1);H2) = (µh.stackify(H1)) | stackify(H2)

stackify((H1|H2);H) = stackify(H1;H) | stackify(H2;H)

stackify((H1;H2);H3) = stackify(H1; (H2;H3))

stackify(H) = stackify(H; ε)

Fig. 17.Thestackify algorithm

Selected rules for the reduction relations and→ on configurations are then spec-ified in Fig. 16 (those not specified are obtained by replacing metavariablesη with S inreductions for other expression forms in Fig. 2). The trace interpretation functionΠ isdefined as forλtrace.

8.2 Stackified Trace Effects

AlthoughλStrace uses stack rather than trace contexts at run-time, we are able to use thetype and verification framework developed previously, assigning types toλStraceexpres-sions in the same manner asλtraceexpressions. The only additional requirement will beto process trace effects– tostackifythem, yielding an approximation of the stack con-texts that will evolve at run-time. The trick is to useµ-delimited scope in trace types,since this corresponds to function scope in inferred types as discussed in Sect. 7, andfunction activations and deactivations induce pushes and pops at run-time. Thestackifyalgorithm is defined inductively in Figure 17. This algorithm works over effects that aresequences; for effects that are not sequences, the last clause massages into sequenceform.

The last three clauses use trace effect equalities characterized in Sect. 3 to “mas-sage” trace effects into appropriate form. Observe that the range ofstackify consists oftrace effects that are all tail-recursive; stacks are therefore finite-state transition systemsand more efficient model-checking algorithms are possible [17].

Example 8.1.With a, b, c representing arbitrary events, and results of stackificationsimplified via effect equivalences to increase readability:

stackify(a; b) = a; b stackify(a; (µh.b)) = a; b stackify((µh.a); b) = a|b

stackify(µh.a|(b;h)) = (µh.a|(b;h))|ε stackify(µh.a|(h; b)) = (µh.a|b|h)|ε

In the second example, sinceµh.a precedesb, butµh.a denotes the effect of a functioncall, stackification specifies that no events precedeb sincea will be popped beforeencounteringb. In the last example, sinceb is preceded byh, which represents recursive

Page 48: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

48 Christian Skalka, Scott Smith, and David Van Horn

µ-scope and hence a recursive call, any events precedingb will be popped beforeb isencountered, hence stackification specifies that no events precedeb. Theεs in the lasttwo examples are artifacts of the transformation, that could be cleaned up with someminor alterations tostackify .

8.3 Properties

In this section we prove a trace approximation result forλStrace (Theorem 8.1), showinghow stackified effects generated byλtrace type inference approximate program tracebehavior in theλStrace model. The result is obtained by simulation ofλStrace in λtrace

(Lemma 8.8), and reuse of trace approximation (Corollary 6.3) forλtrace. Because weare only concerned with showing that stackification is correct, by proving that it yieldsan approximation of program event traces, we omit consideration of checks, since sim-ulation of checks would be a needless complication.

As the basis of the simulation, we define an embeddingL e M of λStrace expressionsin λtrace expressions; expressions are essentially unchanged, except that distinguishedeventspush andpop are inserted in programs to mark function invocation and return.Later, we will define a trace transformation that deduces the stack context from thepush andpop markers.

Definition 8.1. Let cdummy be a distinguished singleton constant, and let:

push , evpush(cdummy) pop , evpop(cdummy)

Then theλStrace to λtrace encoding of expressions, denotedL e M, is defined inductively asfollows:

Lλzx.e M = λzx.push; (λx.pop;x)L e ML ·e· M = (λx.pop;x)L e ML c M = c

L ev(e) M = ev(L e M)Lx M = x

L e1e2 M = L e1 ML e2 ML if e1 then e2 else e3 M = if L e1 M then L e2 Melse L e3 M

L letx = v in e M = let Lx M = L v M in L e M

Given this encoding, it is clear that traces of images in the encoding will be of aparticular formς– everypop event has a matchingpush, with possible nestings, corre-sponding to the activation control flow structure. We specify this form grammatically:

s ::= push; pop | push; s; pop | ε | ev(c) | s; s ev(c) 6∈ {push,pop}ς ::= s | push | ς; ς

The point of the encoding is that a stack context can faithfully be obtained fromtracesς. The proof of simulation will also require that simulation of stack contexts intracesς include a reflection of stack structure– every stack frame connector:: should besimulated by an unmatchedpush. To this end we define the following.

Page 49: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 49

Definition 8.2. The stack context simulation functionsctx is defined as:

sctx(ε) = εsctx(push) = εsctx(ev(c)) = ev(c)

sctx(push; pop) = εsctx(push; ς; pop) = ε

sctx(ς1; ς2) = sctx(ς1) sctx(ς2)

A traceς simulates a stackS, written S ∼ ς, iff the relation can be derived given thefollowing rules.

sctx(ς) = ε

nil ∼ ςS ∼ ς sctx(s) = η

S ::η ∼ ς; push; s

Since stack tracesς are special forms of trace effects, interpretations and equivalenceof them is defined as for trace effects in general. Thus, we can characterizesctx withthe following Lemmas.

Lemma 8.1. If S ∼ ς thenS = sctx(ς).

Lemma 8.2. If ς = ς ′ thensctx(ς) = sctx(ς ′).

The following auxiliary lemma will allow us to “pop” the simulated stack by post-pending apop event, which is essential to simulatingλStraceusingλtracemachinery.

Lemma 8.3. If S ::η ∼ ς, thenS ∼ ς; pop.

Proof. By definition of∼, we have thatς = (ς ′; push; s) wheresctx(s) = η andS ∼ ς ′. The proof then proceeds by case analysis onS.

CaseS = nil. SinceS ∼ ς ′, thereforesctx(ς ′) = ε by definition of∼. But alsosctx(push; s; pop) = ε by definition ofsctx, and also by definition ofsctx we havesctx(ς; pop) = sctx(ς ′) sctx(push; s; pop), i.e. sctx(ς; pop) = ε, soS ∼ ς; pop inthis case by definition of∼.

CaseS = S′ :: η. SinceS ∼ ς ′, thereforeς ′ = ς ′′; push; s′ whereS′ ∼ ς ′′

and sctx(s′) = η by definition of∼. But sincesctx(push; s; pop) = ε by defini-tion of sctx, and alsosctx(s′; push; s; pop) = sctx(s′) sctx(push; s; pop), thereforesctx(s′; push; s; pop) = sctx(s′) = η, soS ∼ ς; pop in this case by definition of∼.

ut

After the following auxiliary lemma, we show that reduction is simulated in theencodingL · M. Note that the proof allows one step ofλStrace reduction to be simulated bymultiple steps inλtrace reduction. The essential feature of the result is the simulation ofstacks by tracesς.

Lemma 8.4. L e M[L v M/x] = L e[v/x] M.

Lemma 8.5. Givenςε = ς such thatS ∼ ςε. If S, e S′, e′ thenς, L e M →? ς ′, L e′ Mwhere there existsς ′ε = ς ′ such thatS′ ∼ ς ′ε.

Page 50: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

50 Christian Skalka, Scott Smith, and David Van Horn

Proof. By case analysis on the rule form of the reductionS, e S′, e′.Caseβ. In this casee = (λzx.e0)v, e′ = ·e0[v/x][e/z]·, andS′ = S :: ε. By

Definition 8.1 we have:

L e M = L (λzx.e0) ML v M Lλzx.e0 M = λzx.push; (λx.pop;x)L e0 M

and sinceL v M is a value by Definition 8.1, therefore byβ:

ς, (λzx.push; (λx.pop;x)L e0 M)L v M

ς, (push; (λx.pop;x)L e0 M)[L v M/x][Lλzx.e0 M/z]

But by definition of substitution and Lemma 8.4:

(push; (λx.pop;x)L e0 M)[L v M/x][Lλzx.e0 M/z]=

push; (λx.pop;x)L e0[v/x][λzx.e0/z] M

and bycontext, event, andseq:

ς,push; (λx.pop;x)L e0[v/x][λzx.e0/z] M→?

ς; push, (λx.pop;x)L e0[v/x][λzx.e0/z] M

But sinceS ∼ ςε by assumption, therefore(S :: ε) ∼ (ςε; push; ε) by definition of∼,and by Definition 8.1:

L ·e0[v/x][λzx.e0/z]· M = (λx.pop;x)L e0[v/x][λzx.e0/z] M

so this case holds, sinceςε; push; ε = ς; push.Casepop. In this casee = ·v·, S = S′ ::η, ande′ = v. By Definition 8.1:

L ·v· M = (λx.pop;x)L v M

and sinceL v M is a value by Definition 8.1, byβ:

ς, (λx.pop;x)L v M ς,pop; L v M

and byevent, seq, andcontext:

ς,pop; L v M→? ς; pop, L v M

Further, by assumptionS′ :: η ∼ ςε, thereforeS′ ∼ ςε; pop by Lemma 8.3, so this caseholds sinceςε; pop = ς; pop.

The rest of the proof follows in a straightforward manner by homomorphism ofL e Min the remaining cases. ut

To extend the simulation result to→ reduction, the encodingL · M needs to be ex-tended to evaluation contexts.

Page 51: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 51

Definition 8.3. The encodingL · M is extended to evaluation contexts as follows, wherea homomorphic extension to other context forms is ellided:

L [ ] M = [ ]L ·E· M = (λx.pop;x)LE MLEe M = LE ML e ML vE M = L v MLE M

L ifE then e1 else e2 M = if LE M then L e1 Melse L e2 M...

After the following auxiliary lemma, we prove a simulation result for→ reduction,which follows easily on the basis of Lemma 8.5. This is immediately followed by themain simulation result, for→? reduction.

Lemma 8.6. LE[e] M = LE M[L e M].

Lemma 8.7. Givenςε = ς such thatS ∼ ςε. If S, E[e]→ S′, E[e′] thenς, LE[e′] M→?

ς ′, LE[e′] M where there existsς ′ε = ς ′ such thatS′ ∼ ς ′ε.

Proof. By contextit is the case thatS, e S′, e′. Thereforeς, L e M →? ς ′, L e′ M wherethere existsς ′ε = ς ′ such thatS′ ∼ ς ′ε, by Lemma 8.5. This meansς, LE M[L e M] →?

ς ′, LE M[L e′ M] by context, and sinceLE M[L e M] = LE[e] M andLE M[L e′ M] = LE[e′] M byLemma 8.6, the result follows. ut

Lemma 8.8 (λStrace Simulation). If nil , e →? S, e′, thenε, L e M →? ς, L e′ M with S =sctx(ς).

Proof. Since nil∼ ε by definition of∼, therefore by Lemma 8.7 and induction on thelength of the reduction nil, e →? S, e′, we can assertε, L e M →? ς, L e′ M where thereexistsςε = ς such thatS ∼ ςε. By Lemma 8.1 it is the case thatsctx(ςε) = S, so byLemma 8.2 the result follows. ut

Having established the dynamic simulation, we now turn to stackification of traceeffects. Our strategy is to show that thesctx transformation of tracesς is containedin the interpretation of stackified effect approximations ofς. The simulation result justproved will then allow us to make the bridge toλStrace stack contexts. First, it will easematters to define an alternate transformation of tracesς, one that “lines up” better withstackification. We do so as follows; note the structural similarity with stackification:

Definition 8.4. Let ς tracesctxs transformation be defined inductively as follows:

sctxs(ε) = εsctxs(ε; ς) = sctxs(ς)

sctxs(push; ς) = sctxs(ς)sctxs(ev(c); ς) = ev(c); sctxs(ς)

sctxs((push; ς; pop); ς ′) = sctxs(ς)|sctxs(ς ′)sctxs((push; pop); ς) = sctxs(ς)

sctxs((ς1; ς2); ς3) = sctxs(ς1; (ς2; ς3))sctxs(ς) = sctxs(ς; ε)

Page 52: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

52 Christian Skalka, Scott Smith, and David Van Horn

We immediately observe thatsctx transformations are contained in trace effect inter-pretations ofsctxs transformations:

Lemma 8.9. sctx(ς) ∈ Jsctxs(ς)K.

Now, the crux of our technique will be to usepush andpop events to line up tracesς with effectsH, and inductively show that thesctxs transformation is approximatedby stackification. However, we want stackification to be more “aware” ofpush andpopevents, and in particular to remove them in stackification, in keeping with thesctxstransformation, so we define an alternate functionstackify ′ with these modifications.The connection withstackify is easily made later, since the modifications are minor;this is becauseµ-scope in effects always corresponds to function scope, which is alwaysdelimited bypush andpop events in images ofL · M (as we prove below).

Definition 8.5. Let stackify ′ be defined equivalently tostackify , except for theµ case,defined as follows:

stackify ′((µh.push;H1; pop);H2) = (µh.stackify ′(H1)) | stackify ′(H2)

The following definition formalizes this special form of effects, inferred for images ofL · M, as thestackifiableproperty of effects.

Definition 8.6. H is stackifiableiff one of the following conditions holds inductively:

1. H ≡ h2. H ≡ ev(c) andev(c) 6= push,pop3. H ≡ H1|H2 and bothH1 andH2 are stackifiable4. H ≡ H1;H2 and bothH1 andH2 are stackifiable5. H ≡ µh.push;H; pop andH is stackifiable

Now, following an important auxiliary lemma necessary to deal withµ-bound ef-fects, we show that ifH approximates a traceς, thenstackify ′(H) approximatessctxs(ς).

Lemma 8.10. Given stackifiableH. Then:

stackify ′(H[µh.push;H; pop/h]) = stackify ′(H)[µh.stackify ′(H)/h]

Proof. Straightforward by induction onh.

Lemma 8.11. For all H, define:

JHKpre = {θ | θ ∈ JHK andθ 6= (θ′ ↓)}

Then, stackifiableH and ς ∈ JHK impliesJsctxs(ς)Kpre ⊆ Jstackify ′(H)K.

Proof. (Sketch) By case analysis on the match forms ofς in the definition clauses ofsctxs and induction on the recursive call tree ofsctxs(ς). By the definitions ofsctxsandstackify ′, and correspondence of the match forms in the defining clauses, it is easy(and tedious) to “line up” the different cases ofς andH, and demonstrate the resultby induction. The most interesting case isς = push; ς ′; pop; ς ′′. It follows in this casethatH must be of the formH = (µh.push;H ′; pop);H ′′, where push; ς ′; pop ∈

Page 53: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 53

Jµh.push;H ′; popK andς ′′ ∈ JH ′′K, since thepush andpop events occur nowhere butat the limits ofµ-scope in stackifiable effects, henceς ′ ∈ JH ′[µh.push;H ′; pop/h]K.Therefore by the induction hypothesis:

Jsctxs(ς ′)Kpre ⊆ stackify ′(H ′[µh.push;H ′; pop/h])Jsctxs(ς ′′)Kpre ⊆ stackify ′(H ′′)

Since:

sctxs(push; ς ′; pop; ς ′′) = sctxs(ς ′)|sctxs(ς ′′)stackify ′((µh.push;H ′; pop);H ′′) = µh.stackify ′(H ′)|stackify ′(H ′′)

It remains to be shown thatJsctxs(ς ′)Kpre ⊆ Jµh.stackify ′(H ′)K. Observing the equal-ity µh.stackify ′(H ′) = stackify(H ′)[µh.stackify ′(H ′)/h] implied by Lemma 3.1, wecan assertµh.stackify ′(H ′) = stackify ′(H ′[µh.push;H ′; pop/h]) by Lemma 8.10.The result follows. ut

Now, we show that type inference generates stackifiable effects. The typing rulesactually don’t “cleanly” placepush andpop events at the limits ofµ-scope, but ratherthere will be intervening cruft such asεs and dummyµ-bindings, due to the nature ofthe encoding of functions. Therefore, a simple transformationf is necessary to obtainan equivalent stackifiable form of effects.

Lemma 8.12. Given satisfiable∅,H `β e : τ/C for closede. Then∅,H ′ `β′ L e M :τ/C ′ is satisfiable, where there exists a functionf such that each of the followingconditions hold:

1. f(hextract C H ′) is stackifiable2. f(hextract C H ′) = (hextract C H ′)3. stackify(hextract C H) = stackify ′(f(hextract C ′ H ′))

Proof. (Sketch) Observe that any effect is stackifiable if the only occurrence ofpushandpop is at the limits ofµ-bound subeffects, and that allµ-bound subeffects havesuch delimitation. Also, the only place whereµ-bound effects occur in(hextract C H)will be in hextract ion of effect variable components ofH in C (in the sense of Defi-nition 7.10). Now, ife is closed, andH has a variable componenth, then it is demon-strable by definition of type inference and Lemma 7.15 thath must have the effectHλ of one or more concrete functionsλzx.e as lower bounds. Furthermore, sinceLλzx.e M = λzx.push; (λx.pop;x)L e M, the lower bounds induced by the transforma-tion Lλzx.e M will be equivalent topush;Hλ; pop (this is approximate; the describedeffect transformation is also carried recursively throughHλ, as the expression transfor-mation is carried recursively through the function body). In short, if(hextract C H)contains a subeffectµh.Hλ, thenf(hextract(H ′, C ′)) will have the same shape as(hextract C H), and will containµh.push;Hλ; pop in the position corresponding toµh.Hλ in (hextract C H). Otherwise, observe thatf(hextract(H ′, C ′)) is homomor-phic to (hextract C H), establishing (2). Since(hextract C H) contains no occur-rences ofpush or pop, thereforef(hextract(H ′, C ′)) contains none aside from thoseat the limits ofµ-scope, and is therefore stackifiable, establishing (1), while (3) followsby definition ofstackify andstackify ′. ut

Page 54: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

54 Christian Skalka, Scott Smith, and David Van Horn

Finally, we can demonstrate correctness ofstackify , by demonstrating a trace ap-proximation result forλStrace via on the strength of the preceding results and trace ap-proximation inλtrace.

Theorem 8.1 (Trace Approximationstackify). If ∅,H `β e : τ/C is satisfiable andalso nil, e→? S, e′, thenS ∈ Jstackify(hextract C H)K.

Proof. First note thate must be top-level, otherwise it would not be typable as inthe premise. Thus by Lemma 8.8, we haveε, L e M →? ς, L e′ M with sctx(ς) = S.By Lemma 8.12 a there exists a satisfiable judgement∅,H ′ `β′ L e M : τ/C ′, withς ∈ Jhextract(H ′, C ′)K by Corollary 6.3. Therefore, by Lemma 8.9 and Lemma 8.11and the equalitysctx(ς) = S, we may assertS ∈ Jstackify ′(hextract(H ′, C ′))K, so theresult follows by Lemma 8.12. ut

9 Verification of Trace Effects

We have described the syntax and semantics ofλtrace, that includes a trace component inconfigurations. We have also described two type and effect systems that conservativelyapproximate run-time traces, and shown that type and effects can be automatically in-ferred. However, we have been abstract so far with respect to the definition of checksand effect verification, basing safety of computation and validity of typing on a yet-to-be-defined notion of check and effect validity. To fill in these details, we define in thisSection:

– A logic for run-time checks, including a syntax for expressing checks as predicatesin the logic, along with a notion of validity for these checks that can be automati-cally verified in the run-time system.

– A means of verifying validity of trace effects, as defined in Definition 3.4, wherecheck events that are predicted by the trace effect analysis are automatically shownto either succeed or fail in the relevant context.

The latter point is necessary to address because, even though validity of trace effectshas been defined, the notion is logical but not algorithmic; in particular,JHK may be aninfinite set. We accomplish automated verification using a temporal logic and model-checking techniques, allowing us to reuse existing algorithms and results for trace effectverification. We use a linear-time logic because the run-time validity of a predicate isbased on one linear traceη only.

9.1 Trace Effects are BPAs

We interpret trace effects as labeled transition systems (Definition 3.3), with a form thatis appropriate for our application. This form is close to that of Basic Process Algebra(BPA) terms; in fact the latter can faithfully represent trace types. Such a representationallows us to apply known model-checking algorithms to our analysis, since several existfor verifying properties of BPAs [37].

Page 55: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 55

Definition 9.1. BPA expressions are defined as follows:

p ::= a | ε | p · p | p+ p | X BPA expressions

Intuitively, eacha denotes a transition action,ε is the empty process,· denotes sequenc-ing, and+ denotes nondeterministic choice. EachX in a BPA process is defined via aset of declarations∆ of the formX , p. We letP range over sets of BPA expressions.The definition of BPA processes is completed via the following operational semantics,whereε · p is considered equivalent top:

pa−→ p′

p+ qa−→ p′

qa−→ q′

p+ qa−→ q′

pa−→ p′

p · q a−→ p′ · qpa−→ p′ X , p ∈ ∆

Xa−→ p′

aa−→ ε

Now, we define a straightforward transformation from trace effects to BPA pro-cesses. We define actionsa in the BPA encoding to be eventsev(c). Note that sinceBPA declarations may include only guarded expressions, the translation is meaningfuljust in case the transformation of aµ-bound trace effect yields a guarded declaration; wetherefore assume a trivial pre-processing of traces to ensure this property, that e.g. couldinsertε before every trace effect variableh:

Definition 9.2. The translation from closed,ε-free trace effectsH to BPA expression,declaration pairsp,∆ is inductively defined as follows. The translation is parameter-ized by an environmentΨ that maps trace effect variablesh to their BPA variable rep-resentationsX in the encoding:

BPA(ε, Ψ) = ε,∅

BPA(ev(c), Ψ) = ev(c),∅BPA(H1;H2, Ψ) = letp1,∆1 = BPA(H1, Ψ) in

letp2,∆2 = BPA(H2, Ψ) in

p1 · p2,∆1 ∪∆2

BPA(H1|H2, Ψ) = letp1,∆1 = BPA(H1, Ψ) in

letp2,∆2 = BPA(H2, Ψ) in

p1 + p2,∆1 ∪∆2

BPA(µh.H, Ψ) = letp,∆ = BPA(H, (Ψ ;h : X)) in

X,∆ ∪{X , p

}X fresh

BPA(h, Ψ) = Ψ(h),∅

For brevity, we write BPA(H) for BPA(H,∅)

The correctness of the translation falls out as a simple corollary:

Corollary 9.1. JHK = JBPA(H)K.

Page 56: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

56 Christian Skalka, Scott Smith, and David Van Horn

JtrueKV = Θ∞

JxKV = V (x)J¬φKV = Θ∞ − JφKV

Jφ1 ∧ φ2KV = Jφ1KV ∩ Jφ2KVJ(a)φKV = {θ∞ ∈ Θ∞ | θ∞ = a; θ∞1 andθ∞1 ∈ JφKV }Jνx.φKV =

⋃{W ⊆ Θ∞ |W ⊆ JφKV [x7→W ]}

Fig. 18.Semantics of the linear-timeµ-calculus

9.2 Verified Checks in the Linearµ-calculus

While a variety of model-checking logics are available, we use theµ-calculus [24]because it is powerful and is syntactically close to trace effectsH. Further, efficienttechniques for the automated verification ofµ-calculus formulas on BPA processes havebeen developed [10, 16]. We use thelinear variant of theµ-calculus [16] because at run-time only one linear trace of events is known, and so trace effectsH and run-time tracesη can only be compared in a linear-time logic.

Definition 9.3. The syntax of the linearµ-calculus is:

φ ::= x | true | false | (a)φ | µx.φ | νx.φ | ¬φ | φ ∨ φ | φ ∧ φ

Here,a ranges over arbitrary transition labels; in particular, we can leta range overeventsev(c). The semantics of the linearµ-calculus is defined in Fig. 18. This semanticsis defined over potentially infinite tracesθ∞ ∈ Θ∞ that, unlike sets of tracesθ, maynot be prefix-closed.V denotes a mapping fromµ-calculus variables to sets of infinitetraces,∅ denotes the empty mapping.JφK is shorthand forJφK∅. Several formulae arenot given in this figure because they can be defined in terms of the others:

φ1 ∨ φ2 ⇐⇒ ¬(¬φ1 ∧ ¬φ2) false ⇐⇒ ¬true µx.φ ⇐⇒ ¬(νx.¬φ)

Since our trace effect semantics is prefix-closed, we will explicitly prefix-closeJφKso the two sets are compatible.

Definition 9.4. The prefix closureΘ∞↓ of a set of infinite tracesΘ∞ is:

{θ | θ is a prefix of someθ∞ ∈ Θ∞}∪

{θ↓ | θ is finite andθ ∈ Θ∞}

Validity of a formulae with respect to a trace effect is defined via set containment of thetrace interpretations of each:

Definition 9.5. The formulaφ is valid forH, writtenH φ, iff JHK ⊆ JφK ↓.

This relation is decidable by known model-checking results and the above equivalenceof BPA processes and trace effects:

Lemma 9.1. The relation isH φ is decidable.

Page 57: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 57

Proof. Model-checking linearµ-calculus formulae over BPA’s is shown decidable in[16]. The key in this construction is that the valid traces of each linearµ-calculus for-mulaφ can be characterized by a finite automaton and Buchi automaton that accept thefinite and infinite traces of¬φ, respectively. Histories can be translated to equivalentBPA’s by Corollary 9.1.

9.3 Relating Trace Effect and Trace Runtime Properties

We now instantiate the logic of trace checks inλtrace with linearµ-calculus formulaeφ. In Lemma 9.1, the relationH φ was shown to be decidable, so this will make anatural foundation for trace effect verification.

One important requirement of this logic is that formulae must have truth values fora given trace effectH, and for a trace runtimeη. The meaning of a formulaφ undera run-time traceη is taken by verifyingη ∈ JφK ↓. We will define the trace checkinterpretation functionΠ of Fig. 2 in terms of this relation (Definition 9.6).

In Corollary 4.1, trace effects were shown to approximate dynamic histories—inparticular, ifε, e →? η, e′ andH,Γ ` e : τ is derivable, thenη ∈ JHK. The key resultlinking the static and dynamic histories is the following:

Lemma 9.2. If η ∈ JHK andH φ, thenη ∈ JφK ↓.

Proof. Immediate from Definition 9.5 and Definition 3.3.

Corollary 4.1 ensures that by the above Lemma, verifying a trace effect entails ver-ifying all trace checks that may occur at run-time, meaning a combination of type in-ference and automated verification yields a sound static analysis forλtrace, as we stateformally in Theorem 9.1.

9.4 Soundness of Verification

We are close to a complete definition of our logical framework for trace checks andtrace effect verification. However, a few small points remain: firstly, inλtrace, we areable to parameterize checks with constants with the syntaxφ(c). To implement this, wespecify a distinguished variableχ that may occur free in trace checks, which is assumedto be instantiated with a trace check parameter during verification.

Secondly, checksφ should express expected trace patterns that may occur up to thepoint of the check. This is the same as requiring that if an eventevφ(c) occurs in a trace(resp. is predicted statically), the sub-traceη that immediately precedes it (resp. anytrace that may precede it as predicted by typing) must exhibit the pattern specified byφ. However, there is an infinite regress lurking here: a propertyφ that mentions aneventevφ(c) suggests circularity in the syntax ofφ. Thus, we introduce a distinguishedlabelNow, that in any formulaφ represents the relevant checkpoint ofφ. This label isinterpreted appropriately during verification. “tacking on” check

We now stand ready to instantiate our logic and verification framework. In the dy-namic system, this is accomplished by defining the language of trace checks, and bydefining the implementation ofΠ, our previously abstract representation of trace checkverification:

Page 58: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

58 Christian Skalka, Scott Smith, and David Van Horn

Definition 9.6 (Definition of Π). The framework of Section 2 is instantiated to letφrange over linearµ-calculus formulae, where labelsa in φ are eventsev(c). Further-more, we distinguish one eventNow to represent checkpoints within the check specifi-cation (hence avoiding circularity), and lettingχ ∈ Vs be a distinguished variable forparameterizing constantsc in φ, we defineΠ as follows:

Π(φ(c), θ) ⇐⇒ θ ∈ Jφ[c/χ][evφ(c)/Now]K ↓

Now, we specify what it means for a trace effect to be verified; intuitively, it meansthat if a trace effectH predicts the occurrence of a check eventevφ(c), thenH seman-tically entailsφ instantiated withc. Formally:

Definition 9.7 (Trace Effect Verification). A trace effectH is verifiableiff for all sub-termsevφ(c) ofH it is the case that:

H φ[c/χ][evφ(c)/Now]

Here is a simple example that demonstrates the system in action:

Example 9.1.Assume we want to define a policy whereby if a particular checkφ(c) isencountered at run-time, the only allowable previous events areev1(c) or ev2(c), andev2(c) must be the most recent event prior to the check. For brevity, let:

(ev1|2(χ))φ , (ev1(χ))φ ∨ (ev2(χ))φ

(ev1|2(χ)∗)φ , µx.(ev1|2(χ))x ∨ φ

The above policy can then be expressed in our scheme with the followingµ-calculusformulaφ:

φ , (ev1|2(χ)∗)(ev2(χ))(Now)true

Now, assuming∅, ε ` e′ : bool, let:

e , if e′ then ev1(c); ev2(c) else ev2(c)

Thus, depending on the valuation ofe′, either:

ε, e;φ(c)→? ev1(c); ev2(c), φ(c)

or:ε, e;φ(c)→? ev2(c), φ(c)

and we see that the check in the program(e;φ(c)) will always succeed at runtime, sincethese relations hold:

ev2(c)evφ(c) ∈ Jφ[c/χ][evφ(c)/Now]K ↓ev1(c)ev2(c)evφ(c) ∈ Jφ[c/χ][evφ(c)/Now]K ↓

We also have that the following judgement is derivable:

∅, (ev2(c)|ev1(c); ev2(c)); evφ(c) ` e;φ(c) : unit

and this entailment holds:

(ev2(c)|(ev1(c); ev2(c))); evφ(c) φ[c/χ][evφ(c)/Now]

Therefore, the judgement is valid, predicting the run-time safety of the program(e;φ(c)).

Page 59: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 59

The preceding construction completes the definition of the framework. Lemma 9.2and definition ofΠ together yield the desired formal property for trace effect verifica-tion as a Corollary:

Corollary 9.2 (Verification Soundness).If H is verified, thenH is valid.

Proof. Immediate by Definition 3.4, Definition 9.6, Definition 9.7, and Lemma 9.2.

This result can then be composed with Lemma 7.22 and Theorem 6.2 to yield a typesafety property for the complete automated analysis.

Theorem 9.1. Suppose∅,H `β e : τ/C is derivable,close(C) is consistent, andhextract C H is verifiable. Thene does not go wrong.

9.5 Incompleteness of Verification

Completeness of verification is a different matter than soundness, and the reader maynotice that our verification technique is approximate. In particular, verification of a traceeffectH (Definition 9.7) with respect to a predicateφ always ensures thatθ ∈ JHKimpliesθ ∈ JφK, regardless of whetherφ occurs inθ, whereas validity (Definition 3.4)only requires that (roughly speaking)θevφ ∈ JHK impliesθevφ ∈ JφK, i.e. validity withrespect to a givenφ is concerned only with traces that end inevφ.

Example 9.2.With φ defined as in Example 9.1, the effect(ev1(c);φ(c)) is both validand verifiable, as is the effectev3(c) since it contains no checks. However, the join ofthe two is not verifiable, sinceev3(c) does not satisfyφ(c), even though it is valid sinceev3(c) precedes no checks and hence is irrelevant to validity:

ev3(c)|(ev1(c);φ(c)) is valid but not verifiable

While this is sound, more precise and complete verification can be obtained with somemodifications. We now show how to enhance verification with a technique that willremove from consideration those traces containing no occurrence of a given formula.

We begin by defining a convenientµ-calculus formula abbreviation, using familiarnotation. This abbreviation will be reused in Sect. 10:

Definition 9.8. Since verification of predicatesφ is always with respect to a particulartrace effectH, and any eventev(c) occurring inJHK must occur inH for the class oftrace effects we consider for verification (see Sect. 9.1), we can easily obtain the set ofpossible events in a trace setJHK as the set of events inH. Lettingev1(c1), · · · , evn(cn)be the events for givenH, we define the following abbreviations:

(.)φ , (ev1(c1))φ ∨ · · · ∨ (evn(cn))φ(.∗)φ , µx.(.)x ∨ φ

A refined, more complete verification can then be defined as follows:

Page 60: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

60 Christian Skalka, Scott Smith, and David Van Horn

Definition 9.9 (Refined Verification).Let theoccurspredicate be defined as follows;a traceθ is in the interpretation of occurs(ev(c)) just in caseev(c) occurs inθ:

occurs(ev(c)) , (.∗)(ev(c))(.∗)true

A trace effectH is thenverified iff for all subtermsevφ(c) ofH, letting:

φ′ = φ[c/χ][evφ(c)/Now]

it is the case that:H φ′ ∨ ¬occurs(φ′)

The soundness results in the previous section can then be replayed in the presence ofthis refined verification.

10 Applications to Language-Based Security

In this section we show that our program logic is sufficiently expressive to be usefulin practice applications including security. In particular, we show how both stack in-spection and history-based security paradigms can be statically enforced in our system.Singleton types allow a precise typing of resource parameters in the model.

In our examples we will be interested in unparameterized events and checks; insuch cases we will writeev andφ for ev(cdummy) andevφ(cdummy) respectively, wherecdummy is a distinguished dummy constant. Also, we will abbreviate eventsev i by theirsubscriptsi, and the notation:

(∨{ev1(c1), . . . , evn(cn)})φ , ev1(c1)φ ∨ · · · ∨ evn(cn)φ

will be convenient.

10.1 Stack inspection with parameterized privileges

Java stack inspection [46, 34, 29] is a language-based security mechanism that uses anunderlying security model of principals and resources– all code is annotated with a prin-cipal identifierp, and a local ACL policyA mapping principalsp to resourcesr(c) forwhich they are authorized is taken as given. An eventevp is issued whenever a codebaseannotated withp is entered. One additional feature of Java is that any principal may alsoexplicitly enablea resource for which it is authorized. When a function is activated, itsassociated principal identifier is pushed on the stack, along with any resource enablingsthat occur in its body. Stack inspection for a particular resourcer(c) then checks thestack for an enabling ofr(c), searching frames from most to least recent, and failingif a principal unauthorized forr(c) is encountered before an enabling ofr(c), or if nosuch enabling is encountered.

Stack inspection can be modeled in the stack-based variant of our programminglogic defined in Section 8. Rather than defining the general encoding, we develop oneparticular example that illustrates all issues. Consider the following function checkit:

checkit, λx.p:system;φinspect,r:filew(x)

Page 61: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 61

(p¬r(c))φ , (∨{p|r(c) 6∈ A(p)})φ(p)φ , (∨({ev1(c1), . . . , evn(cn)} \dom(A)))φ

(¬ev(c))φ , (∨({ev1(c1), . . . , evn(cn)} \ {ev(c)}))φ(a∗)φ , µx.(a)x ∨ φ for a ∈ {p,¬ev(c)}

φenable,r(c) , ¬((.∗)(p¬r(c))(p∗)(Now)true)

φamplify,r(c) , φenable,r(c)

φinspect,r(c) , ¬((¬φenable,r(c)∗)(Now)true) ∧ ¬((.∗)(p¬r(c))(¬φenable,r(c)∗)(Now)true)

φdemand1,r(c) , ¬((.∗)(p¬r(c))(.∗)(Now)true)

φdemand2,r(c) , ¬((¬φamplify,r(c)∗)(Now)true) ∧ ¬((.∗)(p¬r(c))(¬φamplify,r(c)∗)(Now)true)

Fig. 19.Definitions ofφdemand,r andφinspect,r

Every function upon execution first issues an owner (principal) event, in this casep:system indicating “system” is the principalp that owns checkit. The function takes aparameterx (a file name) and inspects the stack for the “filew” resource with parameterx, via embeddedµ-calculus assertionφinspect,r:filew(x). This assertion is defined below;it enforces the fact that all functions on the call stack back to the nearest enable mustbe owned by principalsp that according to ACLA are authorized for ther:filew(x)resource.

To model resource enabling we use a check eventφenable,r(x); the use of a checkevent allows to simultaneously mark a temporary enabling, and to check that enablingis performed by an authorized principal. We illustrate use of explicit enabling via anexample “wrapper” function enableit, owned by the “accountant” principalp:acct, thattakes a functionf and a constantx, and enablesr:filew(x) for the application off tox:

enableit, λf.p:acct; (λx.p:acct;φenable,r:filew(x); lety = f(x) in y)

The definition ofφinspect,r(c), for fixed r(c), is generalized over parameterized re-sourcesr(c). For trace effectH containing only the eventsev1(c1), . . . , evn(cn), andparameterized resourcer(c), Fig. 19 gives the definition ofφinspect,r(c). The check en-sures that it is neither the case that the check occurs without previous enablings ofr(c),nor that a principal unauthorized for the privilege is interposed between the check andthe most recent enabling; this is logically equivalent to stack inspection.

Returning to our previous example expressions checkit and enableit, the followingmost general types are inferred in our system:

checkit: ∀α.{α}p:system;φinspect,r:filew(α)−−−−−−−−−−−−−−−→ unit

enableit: ∀αht.({α} h−→ t)p:acct−−−−→ {α} p:acct;φenable,r:filew(α);h−−−−−−−−−−−−−−→ t

The stackification of thehextracted effect of the application:

enableit checkit(/accts/ledger.txt)

Page 62: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

62 Christian Skalka, Scott Smith, and David Van Horn

will yield the effectp:acct|H, where:

H = p:acct;φenable,r:filew(/accts/ledger.txt); p:system;φinspect,r:filew(/accts/ledger.txt)

This reflects that the call and return of the application(enableit checkit) is assigned theeffectp:acct, while the subsequent application to /accts/ledger.txt is assigned effectH.Assuming that bothp:system andp:acct are authorized forr:filew(/accts/ledger.txt) inA, verification will clearly succeed on this expression. On the other hand, stackificationof the application checkit(/accts/ledger.txt) will generate the following trace effect:

p:system;φinspect,r:filew(/accts/ledger.txt)

for which verification will fail: there is no requiredφenable,r:filew(/accts/ledger.txt) onthe stack.

10.2 History-based access control

History-based access control is a generalization of Java’s notion of stack inspection thattakes into account all past events, not just those on the stack [1]. Our language is wellsuited to the static typechecking of such security policies. In the basic history model of[1], some initialcurrent rightsare given, and with every new activation the static rightsof that activation are automatically intersected with the current rights to generate thenew current rights. Unlike stack inspection, removal of the activation does not returnthe current rights to its state prior to the activation.

We assume the same underlying model of principals as above. A demand of a re-sourcer with parameterc, denotedφdemand1,r(c), requires that all invoked functionspossess the right for that resource. This general check may be expressed in our logicas in Fig. 19, where we assume given for verification some trace effectH containingeventsev1(c1), . . . , evn(cn). For example, validity of the following type judgement re-quiresr(c) ∈ A(p1) ∩ A(p2):

Γ, p1; p2;φdemand1,r(c) ` p1; (λx.p2;φdemand1,r(x)) c : unit

The model in [1] also allows for a combination of stack- and history-based prop-erties, by allowing theamplificationof a right on the stack. When a right is amplified,it remains active after function return regardless of the current rights generated by theinvocation, provided that amplification is performed by an authorized principal. Suchassertions can be expressed in our framework using a combination of stack- and history-based assertions.

Taking the same strategy as for enabling in the stack inspection model, we candefine amplification as a check eventφamplify,r; in fact, this can be defined equivalentto φenable,r, and enforced by stackifying effects before verifying. In other words, thesemantics of amplification are identical to the semantics of enabling. Then, makingthe simplifying assumption that by convention all resources are initially amplified, thedemand predicate can be redefined in the presence of amplification asφdemand2,r inFig. 19. Observe that this predicate is syntactically identical toφinspect,r, except that

Page 63: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 63

effects shouldnot be stackified before verifyingφdemand2,r. The checkφdemand2,r(c) en-sures that an amplification ofr(c) occurs prior to it, without any interposed principalthat is unauthorized forr(c).

Given that history-based access control requires an interplay of stack- and history-based checks, we argue that a contribution of our model is its ability to deal with thesevariations in a uniform manner, within one rigorous formal framework.

11 Conclusion

In this section we conclude with a discussion of related work and a summary of thepaper.

11.1 Related Work

Previous work relevant to the application of trace based security models has been notedin Sect. 1. Here we discuss related theories and systems designed to enforce trace-basedproperties of program execution.

Compile-time vs. Run-time VerificationPerhaps the principal division between previ-ous approaches to the enforcement of trace based program properties is between thosesystems that detect errors at run-time [26, 22, 31, 7, 6, 1, 13],vs.those that detect errorsat compile-time [3, 11, 8, 30]. Run-time approaches are more accurate since a compile-time analysis must conservatively approximate what events could occur; the compile-time analysis will also reject some safe programs, due to the need to be conservative.On the other hand, liveness properties (“all SSL sockets are eventually closed”) can beverified at compile-time but not at run-time.

Run-time VerificationSome early work in the area was carried out by Nierstrasz andother object-oriented language designers [26, 22]. Their goal was to specify only thelegal patterns of messages that could be passed to a particular object. The SSL examplein Sect. 1 could be cast in that view by taking the events to be messages to some SSLcontrol object. Regular expressions and finite automata were used for the specificationlogic in this work. Security automata [31, 7, 6] also use finite automata for specification.Security automata are targeted at specification and verification of security policies. Allof these run-time approaches assume there is a run-time monitoring process that willeither abort or raise an exception if a bad trace is realized. Some automata transitionscan be optimized away using simple static program analyses [15], but the analysis isstill mostly dynamic: errors will not be realized until run-time.

Several groups [1, 13] have proposed using event traces for access control. A givenaccess is only permitted under a restricted set of previous circumstances, recorded in thehistory. These projects propose no particular specification language—the policies aredirectly coded. The stack inspection algorithm used in the .Net CLR and Java SecurityArchitecture is another specific access control policy based on execution history [19].

Page 64: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

64 Christian Skalka, Scott Smith, and David Van Horn

Compile-time VerificationThe MOPS system [11] compiles C programs to Push-downAutomata (PDA) reflecting the program control flow, where transitions are programtransitions and the automaton stack abstracts the program call stack. [21, 8] assume thatsome (undefined) algorithm has already converted a program to a control flow graph,expressed as a form of PDA.

These aforementioned abstractions work well for procedural programs, but are notpowerful enough to fully address advanced language features such as higher order func-tions. Our approach, based on type and effect theory [40, 2], does allow abstract in-terpretation of higher order programs. Trace effects yielded by the analysis provide aconservative approximation of trace behavior via a Labelled Transition System (LTS)interpretation. Program assertions can be expressed as temporal logical formulae thatcan be automatically verified by model-checking [37].

Systems have also been developed for statically verifying correctness of securityautomata using dependent types [45], and in a more general form as refinement types[25]. These systems do not extract any abstract interpretations, and so are in a somewhatdifferent category than the others. They also lack type inference and do not use a logicthat can be automatically verified, so user intervention is needed.

Trace Specification Logics and Model CheckingSome of the aforecited systems alsoautomatically verify assertions at compile-time via model-checking, including [3, 11,8], though none of these define a rigorous process for extracting an LTS from higher-order programs. In these works, the specifications are temporal logics, regular lan-guages, or finite automata, and the abstract control flow is extracted as an LTS in theform of a finite automaton, grammar, or PDA. These particular formats are chosen be-cause these combinations of logics and abstract interpretations can be automaticallymodel-checked.

Perhaps the most closely related work is [23], which proposes a similar type andeffect system and type inference algorithm, but their “resource usage” abstraction isof a markedly different character, based on grammars rather than LTSs. Their systemlacks parametric and subtyping polymorphism, restricting expressiveness in practice,and verifies global, rather than local, assertions. Furthermore, their system analyzesonly history-based properties, not stack-based properties as in our system. The systemof [20] is based on linear types, not effect types. Their usagesU are similar to our traceeffectsH, but the usages have a much more complex grammar and appear to have noreal gain in expressiveness. Their specification logic is left abstract, thus they provideno automated mechanism for expressing or deciding assertions.

The systems in [12, 9, 21, 8] use LTSs extracted from control-flow graph abstrac-tions to model-check program security properties expressed in temporal logic. Theirapproach is close in several respects, but we are primarily focused on the program-ming language as opposed to the model-checking side of the problem. Their analysesassume the pre-existence of a control-flow graph abstraction, which is in the format fora first-order program analysis only. Our type-based approach is defined directly at thelanguage level, and type inference provides an explicit, scalable mechanism for extract-ing an abstract program interpretation, which is applicable to higher-order functions andother features. Furthermore, polymorphic effects are inferable in our system and eventsmay be parameterized by constants so partial dataflow information can be included. We

Page 65: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 65

believe our results are critical to bringing this general approach to practical fruition forproduction programming languages such as ML and Java [36, 32].

Local and Global reasoningLogical assertions can be local, concerning a particularprogram point, or global, defining the whole behavior required. However, access con-trol systems [46, 1, 13], use local checks. Since we are interested in the static enforce-ment of access control mechanisms (see Sect. 10), the focus in this paper is on local,compile-time checkable assertions, though in principle the verification of global prop-erties is also possible in our system. Related work has also modified our basic approachto enforce “policy framings” that support so-called local liveness properties [5].

11.2 Summary

This paper establishes a foundation for the enforcement of local well-formedness prop-erties on program event traces. Our language modelλtraceextends a functional core withconstructs to label program points,akaevents, and with local assertions over programevent traces up to the point of the assertion during evaluation. The language model isparameterized by a logic of event trace assertions and has been instantiated here withthe linearµ-calculus.

We have developed a static type and effect theory forλtraceprograms, whereby com-putational traces arising at run-time can be conservatively approximated by trace ef-fects, components of the type language that are interpreted as model-checkable LTSs.We have presented two variations on the system: the first uses a unified term syntax,while the second uses constraint subtyping. Both include parametric let-polymorphismover types and effects. The unified representation allows for weakening of trace effectsthrough trace containment, whereas the constraint form allows for more expressive typesubsumption. The constraint system is shown to be a conservative extension of both theunified term system and the underlying effect-free ML-style type system. Since traceeffects can be model-checked, verification of trace effect approximations obtained bytyping guarantees that all trace assertions will hold during execution of a give program.Thus, our type safety result guarantees that statically well-typed programs do not con-tain assertions that will fail dynamically.

Type reconstruction algorithms have been defined for both type systems. Type in-ference for constraint subtyping has been shown to be sound and complete, the latterresult entailing a principal types property. Inference is decidable, despite the generalundecidability of trace effect equality and containment, due to a restricted form of con-straints generated by inference. Term forms of trace effects are extractable from effectconstraints via thehextract algorithm, obtaining a compliant form for existing modelchecking techniques.

We have shown that trace effects can be transformed to reflect a stack disciplinefor function calls and returns via thestackify algorithm, allowing the expression ofstack-based policies such as stack inspection and rights amplification for history-basedaccess control. We have also shown how these policies can be defined in our system,as particular applications of a general framework for enforcing trace-based propertiesexpressible in temporal logics. A primary strength of our approach is that the analysisis fully automated—no program abstraction or type annotations are presupposed—and

Page 66: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

66 Christian Skalka, Scott Smith, and David Van Horn

each component of this automation has been rigorously justified. Our static analysisand verification techniques for trace based properties in higher order languages providewell-founded, flexible, and general tools for enforcing program safety and security.

References

1. Martin Abadi and Cedric Fournet. Access control based on execution history. InProceedingsof the 10th Annual Network and Distributed System Security Symposium (NDSS’03), feb2003.

2. T. Amtoft, F. Nielson, and H. R. Nielson.Type and Effect Systems. Imperial College Press,1999.

3. Thomas Ball and Sriram K. Rajamani. Bebop: A symbolic model checker for boolean pro-grams. InSPIN, pages 113–130, 2000.

4. Massimo Bartoletti, Pierpaolo Degano, and Gian Luigi Ferrari. Enforcing secure servicecomposition. InCSFW, pages 211–223. IEEE Computer Society, 2005.

5. Massimo Bartoletti, Pierpaolo Degano, and Gian Luigi Ferrari. History-based access controlwith local policies. In Vladimiro Sassone, editor,FoSSaCS, volume 3441 ofLecture Notesin Computer Science, pages 316–332. Springer, 2005.

6. L. Bauer, J. Ligatti, and D. Walker. More enforceable security policies. InProceedings ofthe Foundations of Computer Security Workshop, 2002.

7. Lujo Bauer, Jarred Ligatti, and David Walker. Types and effects for non-interfering pro-gram monitors. InProceedings of the International Symposium on Software Security, Tokyo,November 2002.

8. F. Besson, T. Jensen, D. Le Metayer, and T. Thorn. Model checking security properties ofcontrol flow graphs.J. Computer Security, 9:217–250, 2001.

9. Frederic Besson, Thomas de Grenier de Latour, and Thomas Jensen. Secure calling contextsfor stack inspection. InProceedings of the Fourth ACM SIGPLAN Conference on Principlesand Practice of Declarative Programming (PPDP’02), pages 76–87. ACM Press, 2002.

10. O. Burkart, D. Caucal, F. Moller, , and B. Steffen. Verification on infinite structures. InS. Smolka J. Bergstra, A. Pons, editor,Handbook on Process Algebra. North-Holland, 2001.

11. Hao Chen and David Wagner. MOPS: an infrastructure for examining security propertiesof software. InProceedings of the 9th ACM Conference on Computer and CommunicationsSecurity, pages 235–244, Washington, DC, November 18–22, 2002.

12. Thomas Colcombet and Pascal Fradet. Enforcing trace properties by program transforma-tion. In27th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages,pages 54–66, 2000.

13. Guy Edjlali, Anurag Acharya, and Vipin Chaudhary. History-based access control for mobilecode. InACM Conference on Computer and Communications Security, pages 38–48, 1998.

14. Jonathan Eifrig, Scott Smith, and Valery Trifonov. Type inference for recursively con-strained types and its application to OOP. volume 1, 1995.http://www.elsevier.nl/locate/entcs/volume1.html .

15. Erlingsson and Schneider. SASI enforcement of security policies: A retrospective. InWNSP:New Security Paradigms Workshop. ACM Press, 2000.

16. J. Esparza. On the decidability of model checking for several mu-calculi and Petri nets. InProceeding of CAAP ’94, volume 787 ofLecture Notes in Computer Science, 1994.

17. J. Esparza, A. Kucera, and S. Schwoon. Model-checking LTL with regular valuations forpushdown systems. InTACS: 4th International Conference on Theoretical Aspects of Com-puter Software, 2001.

Page 67: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

Types and Trace Effects of Higher Order Programs 67

18. Jeffrey S. Foster, Tachio Terauchi, and Alex Aiken. Flow-Sensitive Type Qualifiers. InProceedings of the 2002 ACM SIGPLAN Conference on Programming Language Designand Implementation, pages 1–12, Berlin, Germany, June 2002.

19. L. Gong, M. Mueller, H. Prafullchandra, and R. Schemers. Going beyond the sandbox:An overview of the new security architecture in the Java Development Kit 1.2. InUSENIXSymposium on Internet Technologies and Systems, pages 103–112, Monterey, CA, December1997.

20. Atsushi Igarashi and Naoki Kobayashi. Resource usage analysis. InConference Recordof POPL’02: The 29th ACM SIGPLAN-SIGACT Symposium on Principles of ProgrammingLanguages, pages 331–342, Portland, Oregon, January 2002.

21. T. Jensen, D. Le Metayer, and T. Thorn. Verification of control flow based security properties.In Proceedings of the 1999 IEEE Symposium on Security and Privacy, 1999.

22. Jonathan G. Rossie Jr. Logical observable entities. InOOPSLA, pages 154–165, 1998.23. P. J. Stuckey K. Marriott and M. Sulzmann. Resource usage verification. InProc. of First

Asian Programming Languages Symposium, APLAS 2003, 2003.24. Dexter Kozen. Results on the propositional mu-calculus.Theoretical Computer Science,

27:333–354, December 1983.25. Yitzhak Mandelbaum, David Walker, and Robert Harper. An effective theory of type re-

finements. InProceedings of the the Eighth ACM SIGPLAN International Conference onFunctional Programming (ICFP’03), Uppsala, Sweden, August 2003.

26. Oscar Nierstrasz. Regular types for active objects. InProceedings of the OOPSL ’93 Confer-ence on Object-Oriented Programming Systems, Languages, and Applications, pages 1–15,1993.

27. Jens Palsberg and Patrick O’Keefe. A type system equivalent to flow analysis.ACM Trans.Program. Lang. Syst., 17(4):576–599, 1995.

28. Benjamin C. Pierce.Types And Programming Languages, chapter 22. The MIT Press, 2002.29. Francois Pottier, Christian Skalka, and Scott Smith. A systematic approach to static access

control. In David Sands, editor,Proceedings of the 10th European Symposium on Program-ming (ESOP’01), volume 2028 ofLecture Notes in Computer Science, pages 30–45. SpringerVerlag, April 2001.

30. David A. Schmidt. Trace-based abstract interpretation of operational semantics.Lisp andSymbolic Computation, 10(3):237–271, 1998.

31. Fred B. Schneider. Enforceable security policies.Information and System Security, 3(1):30–50, 2000.

32. Christian Skalka. Trace effects and object orientation. InPPDP ’05: Proceedings of the 7thACM SIGPLAN international conference on Principles and practice of declarative program-ming, pages 139–150, New York, NY, USA, 2005. ACM Press.

33. Christian Skalka and Francois Pottier. Syntactic type soundness for HM(X). ElectronicNotes in Theoretical Computer Science, 75, 2003.

34. Christian Skalka and Scott Smith. Static enforcement of security with types. InProceed-ings of the the Fifth ACM SIGPLAN International Conference on Functional Programming(ICFP’00), pages 34–45, Montreal, Canada, September 2000.

35. Christian Skalka and Scott Smith. History effects and verification. InAsian ProgrammingLanguages Symposium, November 2004.

36. Christian Skalka, Scott Smith, and David Van Horn. A type and effect system for flexible ab-stract interpretation of Java. InProceedings of the ACM Workshop on Abstract Interpretationof Object Oriented Languages, Electronic Notes in Theoretical Computer Science, January2005.

37. B. Steffen and O. Burkart. Model checking for context-free processes. InCONCUR’92,Stony Brook (NY), volume 630 ofLecture Notes in Computer Science (LNCS), pages 123–137, Heidelberg, Germany, 1992. Springer-Verlag.

Page 68: Types and Trace Effects of Higher Order Programsceskalka/skalka-pubs/skalka-smith-vanhorn-trace.pdfJava stack inspection can be encoded with the aid of these parameters. 2.2 Semantics

68 Christian Skalka, Scott Smith, and David Van Horn

38. Chris Stone. Singleton types and singleton kinds. Technical Report CMU-CS-00-153,Carnegie Mellon University, 2000.

39. Martin Sulzmann. A general type inference framework for Hindley/Milner style systems.In International Symposium on Functional and Logic Programming, volume 2024, pages246–263, March 2001.

40. Jean-Pierre Talpin and Pierre Jouvelot. The type and effect discipline. InSeventh AnnualIEEE Symposium on Logic in Computer Science, Santa Cruz, California, pages 162–173,Los Alamitos, California, 1992. IEEE Computer Society Press.

41. Alfred Tarski. A lattice-theoretical fixpoint theorem and its applications.Pacific Journal ofMathematics, 5(2):285–309, 1955.

42. Valery Trifonov and Scott Smith. Subtyping constrained types. InProceedings of the ThirdInternational Static Analysis Symposium, volume 1145, pages 349–365. Springer Verlag,1996.

43. David Van Horn. Trace effect analyis, OCaml implementation.http://www.cs.uvm.edu/˜dvanhorn/trace/ .

44. David Van Horn. Algorithmic trace effect analysis. Master’s thesis, University of Vermont,2006.

45. David Walker. A type system for expressive security policies. InConference Record ofPOPL’00: The 27th ACM SIGPLAN-SIGACT Symposium on Principles of ProgrammingLanguages, pages 254–267, Boston, Massachusetts, January 2000.

46. Dan S. Wallach and Edward Felten. Understanding Java stack inspection. InProceedings ofthe 1998 IEEE Symposium on Security and Privacy, May 1998.