Harmless Advice ∗
Daniel S. Dantas David Walker Princeton University Princeton University [email protected] [email protected]
Abstract number of calls to each method: The what in this case is the com- when This paper defines an object-oriented language with harmless putation that does the recording and the is the instant of time aspect-oriented advice. A piece of harmless advice is a compu- just prior to execution of each method body. In aspect-oriented ter- what advice tation that, like ordinary aspect-oriented advice, executes when minology, the specification of to do is called and the when pointcut control reaches a designated control-flow point. However, unlike specification of to do it is called a . A collection of ordinary advice, harmless advice is designed to obey a weak non- pointcuts and advice organized to perform a coherent task is called aspect interference property. Harmless advice may change the termination an . behavior of computations and use I/O, but it does not otherwise in- Many within the AOP community adhere to the tenet that as- oblivious fluence the final result of the mainline code. The benefit of harmless pects are most effective when the code they advise is to advice is that it facilitates local reasoning about program behavior. their presence [11]. In other words, aspects are effective when a More specifically, programmers may ignore harmless advice when programmer is not required to annotate the advised code (hence- mainline code reasoning about the partial correctness properties of their programs. forth, the ) in any particular way. When aspect- In addition, programmers may add new pieces of harmless advice oriented languages are oblivious, all control over when advice to pre-existing programs in typical “after-the-fact” aspect-oriented is applied rests with the aspect programmer as opposed to the style without fear they will break important data invariants used by mainline programmer. This design choice simplifies after-the-fact the mainline code. customization or analysis of programs using aspects. For exam- In order to detect and enforce harmlessness, the paper defines ple, obliviousness makes it trivial to implement and update an ex- a novel type and effect system related to information-flow type tremely flexible profiling infrastructure. To adjust the places where systems. The central technical result is that well-typed harmless profiling occurs, which might be scattered across the code base, advice does not interfere with the mainline computation. The paper one need only make local changes to a single aspect. Oblivious- also presents an implementation of the language and a case study ness might be one of the reasons that aspect-oriented programming using harmless advice to implement security policies. has caught on with such enthusiasm in recent years, causing major companies such as IBM and Microsoft to endorse the new paradigm Categories and Subject Descriptors D.3.1 [Programming Lan- and inspiring academics to create conferences and workshops to guages]: Formal Definitions and Theory study the idea. On the other hand, obliviousness threatens conventional mod- General Terms Design, Experimentation, Security, Languages, ularity principles and undermines a programmer’s ability to rea- Theory son locally about the behavior of their code. Consequently, many Keywords Aspect-oriented, Harmless Advice, Aspects, Noninter- traditional programming language researchers believe that aspect- ference oriented programs are ticking time bombs, which, if widely de- ployed, are bound to cause the software industry irreparable harm. One central problem is that while mainline code may be syntacti- 1. Introduction cally oblivious to aspects, it is not semantically oblivious to aspects. Aspect-oriented programming languages (AOPL) such as AspectJ Aspects can reach inside modules, influence the behavior of local [17] allow programmers to specify both what computation to per- routines, and alter local data structures. As a result, to understand form as well as when to perform it. For example, AspectJ makes it the semantics of code in an aspect-oriented language such as As- easy to implement a profiler that records statistics concerning the pectJ, programmers will have to examine all external aspects that might modify local data structures or control flow. As the number ∗ This research was supported in part by ARDA Grant no. NBCHC030106, and invasiveness of aspects grows, understanding and maintaining NSF grants CCR-0238328 and CCR-0208601, and an Alfred P. Sloan Fel- their programs may become more and more difficult. lowship. Opinions, findings, conclusions, and recommendations expressed In this work, we define a new form of harmless aspect-oriented throughout this work are not necessarily the views of the NSF, ARDA or advice that programmers can use to accomplish nontrivial program- Sloan foundation and no official endorsement should be inferred. ming tasks yet also allows them to enjoy most of the local reasoning principles they have come to depend upon for program understand- ing, development, and maintenance. Like ordinary aspect-oriented advice, harmless advice is a computation that executes whenever Permission to make digital or hard copies of all or part of this work for personal or mainline control reaches a designated control-flow point. Unlike classroom use is granted without fee provided that copies are not made or distributed ordinary aspect-oriented advice, harmless advice is constrained to for profit or commercial advantage and that copies bear this notice and the full citation prevent it from interfering with the underlying computation. There- on the first page. To copy otherwise, to republish, to post on servers or to redistribute fore, harmless advice can be added to a program at any point in the to lists, requires prior specific permission and/or a fee. development cycle without fear that important program invariants POPL’06 January 11–13, 2006, Charleston, South Carolina, USA. Copyright c 2006 ACM 1-59593-027-2/06/0001. . . $5.00. will be disrupted. In addition, programmers who develop, debug, or enhance mainline code can safely ignore harmless advice, if there for such “harmless” tasks as enforcing consistency in tracing and is any present. logging concerns and for encapsulating monitoring and statistics In principle, one could devise many variants of harmless advice components. We also observed a sequence of emails on the AspectJ depending upon exactly what it means to interfere with the under- users list [13] cataloging uses of aspects with Java projects. Many lying computation. At the most extreme end, changing the timing respondents specified that, in addition to some uncommon uses behavior of a program constitutes interference and consequently, that they wished to highlight, they certainly used AspectJ for the only trivial advice is harmless. A slightly less extreme viewpoint is common aspect-oriented concerns such as profiling, security, and one taken by secure programming languages such as Jif [23] and monitoring mentioned above. Finally, we have done a case study Flow Caml [25]. These languages ignore some kinds of interfer- in security, rewriting the security policies from Evans’ thesis [9] in ence such as changes to the timing and termination behavior of our system, and finding that all but one were harmless. programs, arguing that these kinds of interference will have a min- In the rest of this paper, we develop a theory of harmless advice imal impact on security. However, overall, they continue to place following the same strategy as used in previous work by Walker, very restrictive constraints on programs, prohibiting I/O in high se- Zdancewic, and Ligatti [30] (hereafter referred to as WZL) and in- curity contexts, for instance. Allowing unchecked I/O would make spired by the type-theoretic definition of Standard ML [12]. This it possible to leak secret information at too great a rate. strategy involves defining type-safe languages at two levels of ab- In our case, an appropriate balance point between usability straction: a high-level, user-friendly source language for program- and interference prevention is even more relaxed than in secure mers and a lower-level semantic intermediate language we call the information-flow systems. We say that computation A does not in- core calculus. The core calculus consists of a collection of sim- terfere with computation B if A does not influence the final value ple, orthogonal constructs amenable to formal analysis. The source produced by B. Computation A may change the timing and termi- language is defined by translation into the core calculus. The pri- nation behavior of B (influencing whether or not B does indeed mary reason for this structure is that the source language features return a value) and it may perform I/O. are quite complex—a direct analysis of a deep property such as Now suppose that A is advice and B is the main program. If noninterference would be incredibly difficult and error-prone. We we can establish that A does not interfere with B as defined above, simplify the situation by proving a collection of powerful proper- programmers working on B can reason completely locally about ties of the core calculus. Then, we show that the translation from partial correctness properties of their code. For these properties, source into core is type-preserving and exploit properties of well- they do not need to know anything about advice A or whether or typed core calculus constructs to obtain properties of the source. not it has been applied to their code. For example, if we are work- Overall, this structure helps modularize and simplify an otherwise ing in a functional language like ML and enjoy equational rea- daunting task. soning, all our favorite (partial correctness) equations continue to Section 2 defines the core calculus. The calculus contains primi- hold. If we are working in an imperative language and reason (per- tive notions of pointcuts, advice and a collection of static protection haps informally) using Hoare logic-style pre- and post-conditions, domains, arranged in a partial order. We define a novel type sys- the standard, commonly-used partial-correctness interpretation of tem to guarantee that code, including advice, in a low-protection these pre- and post-conditions continues to be valid. In other words, domain cannot influence execution of code in a high-protection do- many of our most important local reasoning principles remain in- main. Though the type system is directly inspired by information- tact in the presence of harmless advice. flow type systems for security [23, 25, 27], we take advantage of Every time a programmer writes new advice and can guarantee the syntactic separation between advice and code to simplify it. that advice is harmless, he or she will maintain the local reasoning The key technical result for the core language is a proof that the principles so critical to reliable software development. Hence there core calculus satisfies a noninterference property. The proof adapts is great incentive to write harmless advice whenever possible. For- the technique used by Simonet and Pottier in their proof of nonin- tunately, our notion of harmless, non-interfering advice continues terference of Flow Caml [25] to our aspect-oriented language. to support many common aspect-oriented applications, including Section 3 develops a surface language that is more amenable the following broad application classes. to programming. In particular, the high-level language is oblivi- • ous, and therefore “aspect-oriented” according to Filman and Fried- Profiling. Harmless advice can maintain its own state separate man’s definition, whereas the core calculus is not.1 The source lan- from the mainline computation to gather statistics concerning guage allows programmers to define aspects that are collections of the number of times different procedures are called. When state, objects, and advice. Each aspect operates in a separate static the program terminates, the harmless advice can print out the protection domain and does not interfere with the mainline com- profiling statistics. putation or the other aspects. This section defines the syntax of the • Invariant checking and security. Harmless advice can check in- source language and establishes its semantics through a translation variants at run-time, maintain access control tables, perform from source into core. We prove that source language aspects are resource accounting, and terminate programs that disobey dy- harmless by exploiting properties of the core calculus. In addition, namic security policies. we present example code implemented in our system and explain a case study in security we have performed. • Program tracing and monitoring. Harmless advice can print out Section 4 discusses related work in more detail and Section 5 a variety of debugging information including when procedures concludes. are called and what data they are passed. • Logging and backups. Harmless advice can back up data onto 2. Core Calculus persistent secondary storage or make logs of events that occur during program execution for performance analysis, fault re- Our core calculus is a typed lambda calculus containing strings, covery, or postmortem security audits. booleans, tuples, references, and simple objects. The two main
We have also accumulated anecdotal evidence that indicates 1 It is neither necessary nor the slightest bit desirable for the core calculus enough important applications appear to fall into this category to to be oblivious, as the syntax of the core calculus does not limit or constrain make it a useful abstraction. For example, IBM experimented with programmers in any way. Programmers need only concern themselves with aspects in their middleware product line [4], finding them useful the source language, which is oblivious. features of interest in the language are labeled control-flow points p ∈ Protections s ∈ Strings x ∈ Identifiers and advice, both of which are slight variants of related constructs l ∈ Labels r ∈ Reference Locations introduced by WZL. τ ::= unit | string | bool | τ1 × ... × τn | τ →p τ Labels l, which are drawn from some countably infinite set, 1..n | [mi:p τi] | advicep | τ labelp | τ refp mark points in a computation at which advice may be triggered. For i | τ pcd instance, execution of l[e1]; e2 proceeds by first evaluating e1 until p it reduces to a value v and at this point, any advice associated with v ::= () | s | true | false | (~v) | λpx : τ.e 1..n ~ the label l executes with v as an input. Once all advice associated | [mi = ςpi xi.ei] | {v.x →p e} | l | r | {l}p with l has completed execution, control returns to the marked point e ::= v | x | e1; e2 | print e | if e1 then e2 else e3 and evaluation continues with e2. A marked point l[e1] has type | (~e) | split(~x)= e in e | e e | e.m | {e.x →p e} unit, and no data are returned from the triggered advice. This stands | ⇑ e | newp : τ | e[e] | refp e | ! e | e := e in contrast to earlier work by WZL, in which labels marked control- | {~e}p | e ∪p e | p
0 0 Γ ` true : bool Γ ` false : bool ·; p ` e : τ ` p ≤ p Γ; p ` p0 >e< : τ 1≤i≤n 0 (Γ ` vi : τi) Γ, x : τ; p ` e : τ 0 This rule raises the protection domain for the expression e and Γ `(~v): τ1 × ... × τn Γ ` λpx : τ.e : τ →p τ allows information to flow out of the expression, but does not allow any information to flow in. In the context of the features we have 1..n (1≤j≤n) ((Γ, x : [mi:pi τi] ); pj ` ej : τj ) looked at so far, this rule appears sound, but in combination with 1..n 1..n the context-sensitive advice we will introduce in Section 2.4, it is Γ ` [mi = ςp xi.ei] : [mi:p τi] i i not. Fortunately, the rule does not appear useful in our application 2 0 0 and we have omitted it. Γ ` v : τ pcd Γ, x : τ; p ` e : unit ` p ≤ p p The last component of our type system involves the rules for Γ ` {v.x →p0 e} : advicep0 typing advice and marking control-flow points. If we want to ensure that low-protection code cannot interfere with high-protection code Γ(l) = τ labelp Γ(r) = τ refp by manipulating advice and control-flow labels, we must be sure
Γ ` l : τ labelp Γ ` r : τ refp that low-protection code cannot do either of the following: 1. Declare and activate high-protection advice. For instance, as- (1≤i≤n) (1≤i≤n) (Γ ` vi : τ labelpi ) ( ` p ≤ pi) sume r is a high-protection reference with type int refhigh and l is a label that has been placed in high-protection code. If Γ ` {~l}p : τ pcd p we allow the expression Figure 2. Core Calculus: Value Typing ⇑ {l.x →high r := 3 + x}; e to appear in low-protection code, then this low privilege code can indirectly cause writes to the reference r. (the advice, written elsewhere) than there might be in a standard 2. Mark a control-flow point with a label that triggers high- secure information-flow setting. We believe this is the right design protection advice. For instance, assume that choice for us because it simplifies the type system, as we do not {l.x → r := 3 + x} have to annotate basic data such as booleans, strings, or tuples with high information flow labels. is an active piece of high-protection advice which writes to Most of the value typing rules in Figure 2 are straightforward. the high-protection reference r. Placing the label l in low- For instance, the rule for functions λpx : τ.e, states that the body protection code allows low-protection code to determine via its of the function must be checked under the assumption that the code control-flow, when the high-protection advice will run and write operates in protection domain p. The resulting type has the shape to r. 0 τ →p τ . Checking our simple objects is similar: the type checker must verify that each method operates correctly in the declared In order to properly protect high-protection code in the face of protection domain. Labels and references are given types by the these potential errors, we do the following. context. In the current calculus, point-cut designators are sets of 1. Add protection levels to advice types (e.g., advicehigh), which labels. Unlike the other values, the rules for typing advice are fairly will allow us to prevent advice from being activated in the subtle. We will discuss these rules, along with the rules for typing illegal contexts. (eg. low-protection contexts) labeled control-flow points, in a moment. The first few expression typing rules in Figure 3 are standard 2. Add protection levels to label types (e.g., string labelhigh) rules for type systems that track information flow. The rule for if which will allow us to prevent labels being placed in illegal deviates slightly from the usual rule for tracking information flow. spots. (eg. low-protection contexts) Normally, types for booleans will contain a security level and the One might hope that it would be possible to simplify the system and branches of the if will be checked at a level equal to the join of add protection levels to only one of the two constructs, but doing the current security level and the level of the boolean. However, in so leads to unsoundness. our system, any data, including booleans, manufactured by code at Several typing rules in the middle of Figure 3 give the well- level p contains level p information. Consequently, the branches of formedness conditions for advice and labels. Notice that in the rule the if statement may be safely checked at level p. The typing rules for typing advice introduction ({e1.x →p e2}), the protection level for function calls and method invocations require that the function of the advice, and therefore the protection level the body of the or method in question be safe to run at the current protection level advice must operate under, is connected to the protection level of p. the label that triggers it. Second, given a high-protection piece of The typing rules for references enforce the usual integrity con- advice, this advice cannot be installed (⇑ e) from low-protection straint found in information-flow systems. When in protection do- code. Finally, notice that when marking a control-flow point with a main p, we are allowed to dereference references in protection do- 0 0 label (e1[e2]), the protection level of the label is connected to the main p when p is less than or equal to p . We are allowed to store protection level of the expression at that point. The result of these to references in protection domain p0 only if our current domain p 0 constraints is that when in a low-protection zone, there is no way is greater than or equal to p . to cause execution of high-protection advice. The last rule in Figure 3 is a typing coercion that changes the protection level. It is legal for the protection level to be lowered 2 0 There may well be some strategy that allows us to add this rule together from p to p when no information flows back from the computation with the context-sensitive advice of Section 2.4. However, the naive ap- e to be executed. We prevent this information flow by constraining proach does not appear to work. Rather then complicating the type structure the result type of e to be unit. One might wonder whether the or operational semantics for something we do not need, we leave it out. 2.3 Operational Semantics The definition of the operational semantics for our language largely Γ(x) = τ Γ ` v : τ follows earlier work by WZL. In particular, we use a context-based Γ; p ` v : τ Γ; p ` x : τ semantics where contexts E specify a left-to-right, call-by-value evaluation relation. The top-level operational judgment has the Γ; p ` e1 : unit Γ; p ` e2 : τ form (S, A, p, e) 7−→ (S0, A0, p, e0) where S collects the labels Γ; p ` e1; e2 : τ l that may be used to mark control-flow points and also maps reference locations r to values. The meta-variable A represents an Γ; p ` e : string advice store, which is a list of advice. The current protection level Γ; p ` print e : unit of the code is p. The protection level does not influence execution of the code, and could be omitted, but is useful to consider in Γ; p ` e1 : bool Γ; p ` e2 : τ Γ; p ` e3 : τ our noninterference proof. Most of the real work is done by the 0 0 0 Γ; p ` if e1 then e2 else e3 : τ auxiliary relation (S, A, p, e) 7−→β (S , A , p, e ). The syntax of stores and advice stores is given below. 1≤i≤n (Γ; p ` ei : τi) S ::= · | S, r = e | S, l ( ) 1 Γ; p ` ~e : τ × ... × τn A ::= · | A, {v.x →p e} The definitions of these relations can be found in Figure 4. ~ Γ; p ` e1 : τ1 × ... × τn Γ,(~x : t); p ` e2 : τ Notice that the rule for marked control-flow points depends upon Γ; p ` split(~x)= e1 in e2 : τ an auxiliary function A[[A]]l[v] = e. This function selects all advice in A that is triggered by the label l and combines their Γ; p ` e1 : τ1 →p τ2 Γ; p ` e2 : τ1 bodies to form the expression e. The advice composition func- Γ; p ` e1 e2 : τ2 tion can be found in Figure 5. Finally, an abstract machine con- figuration (S, A, p, e) is well-typed if it satisfies the judgement 1..n Γ; p ` e : [mi:pi τi] 1 ≤ j ≤ n p = pj `(S, A, p, e)ok specified in Figure 6. Γ; p ` e.mj : τj 2.4 Context-Sensitive Advice 00 00 0 The advice defined in previous sections could not analyze the call Γ; p ` e1 : τ pcd 0 Γ, x : τ; p ` e2 : unit ` p ≤ p p stack from which it was activated. Programming languages such Γ; p ` {e1.x →p00 e2} : advicep00 as AspectJ allow this flexibility via special pointcut designators such as cflow. In this section, we describe a fully general facility 0 Γ; p ` e : advicep0 ` p ≤ p for analysis of information on the current call stack. Our new Γ; p `⇑ e : unit mechanism is inspired by earlier work by WZL, but is more general and fits better with the functional programming paradigm. Figure 7 ` p0 ≤ p outlines the syntactic extensions to our calculus. In order to program with context-sensitive advice, programmers Γ; p ` new 0 : τ : τ label 0 p p grab the current stack using the stack()command. Data is explic- itly allocated on the stack using the command store e1[e2] in e3, Γ; p ` e1 : τ labelp Γ; p ` e2 : τ where e1 is a label and e2 represents a value associated with the Γ; p ` e1[e2] : unit label. e2 is typically used to store the value passed into the control flow point marked by the label. The store command evaluates e1 Γ; p ` e : τ ` p0 ≤ p to a label l and e2 to a value v2, places l[v2] on the stack, evaluates Γ; p ` refp0 e : τ refp0 e3 to a value v3 and finally removes l[v2] from the stack and re- turns v3. The programmer may examine a stack data structure using 0 Γ; p ` e : τ refp0 ` p ≤ p the case e of (pat ⇒ e | ⇒ e)command, which matches the Γ; p `!e : τ stack e against the pattern pat. If there is a match, the first branch is executed; otherwise, the second branch is executed. There are 0 Γ; p ` e1 : τ refp0 Γ; p ` e2 : τ ` p ≤ p patterns that match the empty stack (·), patterns that match a stack starting with any label in a particular set ({~l}p[x] :: pat) where Γ; p ` e1 := e2 : τ x is bound to the value associated with the label on the top of the (1≤i≤n) 0 (1≤i≤n) stack if it is in the label set, patterns that match a stack starting with (Γ; p ` ei : τ labelpi ) ( ` p ≤ pi) anything at all ( :: pat), and patterns involving stack variables (x). Γ; p ` {~e}p0 : τ pcdp0 The typing rules for these extensions appear in Figure 8. There are three sets of rules in this figure. The first two extend the value 0 1 1 typing and expression typing relations respectively. The last set of Γ; p ` e : τ pcdp1 ` p ≤ p 0 rules gives types to patterns where the type of a pattern is a context Γ; p ` e2 : τ pcdp ` p ≤ p2 2 Γ that describes the types of the variables bound within the pattern. Γ; p ` e1 ∪p0 e2 : τ pcdp0 The rules for evaluating these new expressions appear in Fig- ure 9. Again, there are three sets of rules. The first defines a new 0 0 Γ; p ` e : unit ` p ≤ p set of top-level evaluation rules, and the second adds additional β- Γ; p ` p0
(S, A, p,(); e)7−→β (S, A, p, e) `(S, A, p, e)ok
(S, A, p, print s)7−→β (S, A, p, ()) Figure 6. Core Calculus: Abstract Machine Judgement
(S, A, p, if true then e1 else e2)7−→β (S, A, p, e1) τ ::= ... | stack (S, A, p, if false then e1 else e2)7−→β (S, A, p, e2) v ::= ... | · | l[v] :: v e ::= ... | stack() | store e[e] in e (S, A, p, split(~x)=(~v)in e)7−→β (S, A, p, e[~v/~x]) | case e of(pat ⇒ e | ⇒ e) pat ::= nil | e[x] :: pat | :: pat | x (S, A, p, λpx : t.e v)7−→β (S, A, p, e[v/x]) vpat ::= nil | {~l}p[x] :: vpat | :: vpat | x 1..n E ::= ... | store E[e] in e | store l[E] in e (S, A, p, [mi = ςpi xi.ei] .mj )7−→β 1..n | store l[v] in E (S, A, p, ej [[mi = ςpi xi.ei] /xj ]) | case E of(pat ⇒ e | ⇒ e) | case v of(Epat ⇒ e | ⇒ e) (S, A, p, ⇑ {v.x →p0 e1})7−→β (S,(A, {v.x →p0 e1}), p,()) Epat ::= E[x] :: pat | {~l}p[x] :: Epat | :: Epat F ::= ... | [] | store l[v] in F | p < F > ( ) ( new 0 ) (( ) ) l ∈/ S S, A, p, p : τ 7−→β S, l , A, p, l | E[F ] where E 6= store l[v] in F l ∈ S A[[A]] = e l[v] Figure 7. Context Sensitive Advice Syntax (S, A, p, l[v])7−→β (S, A, p, e)
(r ∈/ S) (S, A, p, refp0 v)7−→β ((S, r = v), A, p, r) Γ ` v : τ
(S, A, p, ! r)7−→β (S, A, p, S(r)) Γ ` · : stack
Γ ` l : τ labelp Γ ` v1 : τ Γ ` v2 : stack (S, A, p, r := v)7−→β ((S, r = v), A, p, v) Γ ` l[v1] :: v2 : stack ~ ~ ~ ~ (S, A, p, {l1}p1 ∪p0 {l2}p2 )7−→β (S, A, p, {l1 l2}p0 ) Γ; p ` e : τ (S, A, p, p0<()>)7−→ (S, A, p, ()) β Γ; p ` stack(): stack
Figure 4. 0 0 Core Calculus: Operational Semantics Γ; p ` e1 : τ labelp0 Γ; p ` e2 : τ Γ; p ` e3 : τ Γ; p ` store e1[e2] in e3 : τ
Γ; p ` e1 : stack 0 0 Γ; p ` pat ⇒ Γ Γ, Γ ; p ` e2 : τ Γ; p ` e3 : τ Γ; p ` case e1 of(pat ⇒ e2 | ⇒ e3): τ A[[·]]l[v] =() Γ; p ` pat ⇒ Γ ~ l ∈ {l}p0 A[[A]]l[v] = e Γ; p ` nil ⇒ · ~ 0 0 A[[{{l}p0 .x →p e }, A]]l[v] = p
(S, A, p, e)7−→(S0, A0, p, e0) 0 0 0 (S, A, p, e)7−→top (S , A , p, e )
(S, A, p, F [stack()])7−→top (S, A, p, F [S(F )]) where : S([])= · S(store l[v] in F )= S(F )@(l[v]) S(p < F > )= S(F ) S(E[F ])= S(F ) when E 6= store l[v] in F
(S, A, p, e)7−→β (S, A, p, e)
(S, A, p, store v1[v2] in v3)7−→β (S, A, p, v3)
v |= vpat ⇒ sub
(S, A, p, case v of(vpat ⇒ e1 | ⇒ e2))7−→β Figure 10. Noninterference Proof Diagram (S, A, p, sub(e1))
v 6|= vpat ⇒ sub (L). The low-protection group is a downward-closed subset of pro- tection domains and the high-protection group contains all other (S, A, p, case v of(vpat ⇒ e1 | ⇒ e2))7−→ β protection domains. The goal is to prove that low-protection code (S, A, p, e2) cannot interfere with the behavior of high-protection code, no mat- v |= vpat ⇒ sub ter how aspects, references or labels are used. Overall, our proof may be broken down into four main steps (See also Figure 10):
· |= nil ⇒ · • Define a new language Core2 whose programs simulate execu- tion of two original (henceforth referred to as Core1) programs. ~ l ∈ {l}p v2 |= vpat ⇒ sub • Show Core2 is a correct simulation of Core1 programs via l[v1] :: v2 |= {~l}p[x] :: vpat ⇒ sub, [v1/x] Soundness and Completeness theorems. • Prove Core2 is a safe language and preserves the noninterfer- v2 |= vpat ⇒ sub ence invariants via the standard Progress and Preservation the- l[v1] :: v2 |= :: vpat ⇒ sub v |= x ⇒ [v/x] orems. • Put the theorems above together to prove the noninterference Figure 9. Advanced Pointcut Designator Evaluation result for Core1. rules conclude in judgments with the form st |= vpat ⇒ sub. 2.5.1 Defining Core2 These rules describe the circumstances under which a stack st matches an (evaluated) pattern vpat and generates a substitution We begin by defining a new language (Core2) that simulates ex- of values for variables sub. ecution of two of our original programs. For the full details of For the most part, it is relatively straightforward to reassure the grammar and semantics of Core2, see Appendix A. The main oneself that these extensions will not disrupt the noninterference syntactic difference between Core1 expressions and Core2 ex- properties that our language possesses. However, there is one ma- pressions is the “brackets expression”, p
Figure 11. Source Language Syntax Advice in the source language is either before advice that runs before a method call or after advice that runs after the method call. Similar to the source-language stack patterns, when the advice is As we have already shown, it is possible to prove deep proper- triggered, x is bound to self, y is bound to the method argument, ties of the core, including our powerful noninterference result. The and n is bound to a string corresponding to the method name. The primary reason for this is that core calculus consists of a relatively variable s is bound to the stack at the point the advice is triggered. simple, orthogonal collection of primitive operators. In a more con- In the source language, programmers do not explicitly allocate their venient source language, these simple operators are combined to- own data on the stack, nor do they explicitly grab the current stack. gether to form complex, higher-level primitives. To obtain prop- Code for performing these actions is emitted at specific points erties of a source language, we give a type-preserving translation during the translation from source into core. into the core and then exploit properties of type-correct core calcu- lus terms. This strategy effectively modularizes proofs of properties 3.2 Examples about the source and greatly simplifies the overall proof. Figure 12 and 13 display example code.3 Figure 12 presents the Hence, in this section, we proceed to define a user-friendly (partial) definition of the sys object, which implements a number aspect-oriented source language with harmless advice. We have im- of system calls. We have shown some of the file operations here. plemented the language in SML and explored the extent to which Figure 13 presents three simple security policies we have imple- we can use harmless aspects to implement dynamic security poli- mented to exhibit the basic language features. Programmers would cies. use these aspects to sandbox untrusted code [2, 8, 10, 19]. The first policy, limitdirectories, disallows programs from 3.1 Syntax opening files in directories other than the tests directory. This is Figure 11 presents the formal syntax of the source language. The achieved using before advice that is triggered by execution of any types of the source language objects are a restricted form of the of the open-file calls in the sys object. The before advice checks internal language types. In particular, source language object types the method call argument to determine the file to be opened. If the are the composition of a core calculus object and function type. file is not in the right directory the advice prints out a message and Also, since programmers in the source language do not explicitly aborts, terminating the program. This advice calls a number of manipulate labels, there are no label types in the source language. pure string functions as well as the print and abort functions, Most of the source language expressions and values mimic the which have I/O and termination effects. Our type system correctly core calculus expressions and values, although there are a few verifies it is harmless. differences. For instance, none of the run-time-only values such The second example, limitcreate, limits the number of new as labels, reference locations, or stack values need appear in the files a program can create. To do so, it allocates a local reference collection of source values, as the source language is not executed filescreated to keep track of the number of files created so far. directly. Also, for convenience, we allow a local let declaration in By default, such references take on the protection level of the aspect expressions, which programmers can use to allocate values with that creates them, in this case limitcreate. Once again, the type basic types, reference type, or object type. Note that we use the system verifies that the aspect is harmless. Notice that even though meta-variable o to stand for program variables bound to objects. We limitcreate and limitdirectories can be invoked at some of use the meta-variable x to stand for any kind of program variable. the same control flow points (e.g., sys.openC), they are guaranteed The source language case expressions analyze stack values in not to interfere. Hence, these two policies could have being created a similar way to the target, only the patterns are slightly different, by independent programmers and they would still work properly reflecting a particular compilation strategy. More specifically, when when composed. compiling a method, we will automatically allocate the following The last example, opencheck, shows how to use stack patterns items on the stack: a label corresponding to the method and a tuple to implement a highly simplified stack-inspection-like policy. In containing a pointer to self, a pointer to the method argument, and this example, we have assumed that sys.openC and sys.openO a string corresponding to the name of the method that was called. are “helper functions” that should only be called by sys.openW, Consequently, the patterns that match stack frames have the form which checks to see whether or not the file in question exists before 1..n 1..n {o.mi} [x, y, n], where {o.mi} is checked against the label, determining which method to call. In this aspect, before advice and x, y, and n are bound to self, the argument and the string respectively. The string can be used when printing out debugging 3 These examples use a number of additional standard operations we have information, profiling information, etc. not formalized, but we have implemented in our system. limitdirectories:{ • LimitWrite prevents the modification of existing files and lim- (string alloweddirectory = "tests/") its the number of characters that can be written to the file sys- (before {sys.openR, sys.openW, sys.openA, sys.openC, tem. sys.openO} (x,y,s,n) = • let NetLimit restricts the network send rate to a designated limit. (string directory = When the rate is being exceeded, our implementation uses substring (y, 0, (lastindexof (y, "/")+1))) sleep system calls to slow the send process. This is allowed in in our definition of harmlessness. (if (directory == alloweddirectory) • JavaApplet only allows access to a specified file and only al- then () lows connections to a specified host. Our harmless implemen- else ((print "Forbidden directory.\n"); tation contains aspects on the relevant read, write, observe file (abort ())) )) system calls and on the relevant connect and accept network } system calls. • Paranoid implements file read, write, create and observe limits, limitcreate:{ directory restrictions, and network usage prevention. (ref filescreated:int = 0) • (int createlimit = 10) TarCustom is a modified NoBashingFiles policy except “.tar” (before {sys.openC} (x,y,s,n) = files can be overwritten. It only allows read access to specified if ((!filescreated + 1) > createlimit) files, does not allow more bytes written than read, and prohibits then ((print "Too many files created.\n"); all network use. (abort ())) else ()) 3.4 Source Language Metatheory (after {sys.openC} (x,y,s,n) = To gives a semantics to our source language, we define a type- ((filescreated := (!filescreated) + 1); ())) preserving transformation into the core language. More precisely, } we define a type-preserving transformation into Core2, which gives us not one, but two semantics for the source. The first se- opencheck:{ mantics is the reference semantics in which every source language (before {sys.openC, sys.openO} (x,y,s,n) = aspect is translated into the unit value. In this semantics, aspects case s of cannot possibly be anything but harmless. The second semantics ( _::{sys.openW}[x,y,n]::tail => () is the implementation semantics. In this latter case, every source | _ => (print ("Invalid openW call.\n"); language aspect is implemented as the appropriate core language abort ()))) state, objects and advice. Each new aspect is placed in its own new } protection domain, which sits underneath the protection domain main for the mainline code in the security lattice. Clearly, one im- Figure 13. Simple Security Aspects plements the second (implementation) semantics not the reference semantics. However, using the key properties of the core — sound- ness, completeness and preservation — we prove that if the two analyzes the control stack (advice argument s) and only allows semantics both terminate and produce results, then the results they execution to proceed if the immediate caller was sys.openW. Real produce are equal. Consequently, we obtain our central result: the stack inspection policies examine the whole control stack, not just implementation semantics of source language aspects is harmless. the immediate caller. Such policies may be implemented in our Overall, the translation is defined as a collection of mutually re- system using a recursive method that runs down the stack. cursive judgements that both type check the source and simultane- ously translate it into the core. In general, the judgements have the 3.3 A Case Study in Security ann form P ; Γ; p ` source : τ =⇒ core where P describes the pro- To study the usefulness of harmless advice somewhat more broadly gram points that may trigger advice, Γ is a source typing context, in the security domain, we examined the suite of security policies p is the protection domain for the code, source is source-language that Evans implemented as part of the Naccio system for his the- syntax to be translated, τ is its type, and core is the Core2 language sis [9]. At the time, Evans thought of Naccio as a domain specific code that results. The annotation ann above the arrow indicates the language for implementing security policies, and he argued effec- sort of source syntax that is being translated (e.g., dec for declara- tively (as did Erlingsson and Schneider in concurrent research [8]) tions, as for aspect declarations, etc.,). that his language, which completely separates security code from For full details on the translation, see Appendix B. We now mainline program, was an effective means of developing reliable show one key rule that gives source-level aspects two interpreta- security policies. It is now clear that Naccio is form of aspect- tions in the core: oriented programming language, though at the time Naccio was 0 as 0 developed, aspects had not yet gained much attention. P ; Γ; p ` as; .;(): unit =⇒ e dec We lifted the security policies Evans wrote for Java from his P ; Γ; main ` .; asps; e : τ =⇒ e00 ` p0 < main thesis and rewrote them in our language, testing them for harmless- dec ness. We omitted those elements of the policies that were particu- P ; Γ; main ` .; p0:{as} asps; e : τ =⇒ p0<()|e0>; e00 larly Java-specific. Of the group, there was one policy that was not This rule translates one aspect (p0:{as}) in a sequence into a Core2 harmless. It was a networking policy called SoftSendLimit that di- 0 vided up the data to be sent on the network into small chunks and expression. Assuming e is the code that results from translating as, the declarations that make up the aspect, then the resulting Core2 limited the sending rate to some preset limit. Some of the other 0 0 policies we investigated include the following: expression is p <()|e >. In this case, the reference semantics for the aspect is()and the implementation semantics is e0. • NoBashingExceptTmp allows modification of files in the The first important property of the translation is that it only “tmp” directory but no others. produces well-typed Core2 expressions. THEOREM 3.1 (Translation Type Safety). Two pieces of advice are strongly independent when they do not prog 0 0 If ` prog : bool =⇒ e , then .; main `2 e : bool. interfere with each other regardless of the contents of the advice bodies or the contents of the programs they are applied to. In other The Translation Type Safety Theorem, when combined with words, strong independence is determined exclusively by analysis properties of the core, gives us our final theorem establishing that of the pointcut designators of the two pieces of advice and con- the reference and implementation semantics of the source language sequently it is orthogonal to our analysis which (mostly) ignores coincide and therefore that aspects are harmless. The proof has the pointcuts and examines the advice bodies instead. It would be a similar structure to the proof of noninterference for the core interesting to explore how to put these two different ideas together. covered in Section 2.5. Krishnamurthi, Fisler and Greenberg [20] tackle the more gen- eral problem of verifying aspect-oriented programs. Given a set of THEOREM 3.2 (Source Language Aspects are Harmless). prog properties a program must satisfy, specified in a temporal logic, If ` prog : bool =⇒ e0 0 ∗ and a set of pointcut designators, they verify programs using model and(·, ·, main, |e |1)7−→top (S1, A1, main, v1) checking. Their approach to verification is partly modular since 0 ∗ and(·, ·, main, |e |2)7−→top (S2, A2, main, v2) as long as the set of pointcuts does not change and the under- then v1 = v2. lying mainline code remains fixed, it is not necessary to reana- lyze the mainline code as advice definitions are edited. However, 4. Related Work if the pointcuts or mainline code do change, the whole program must be rechecked. Aside from the fact that we are both interested Over the last several years, a number of researchers have begun in modular checking of aspect-oriented programs, there is not too to build semantic foundations for aspect-oriented programming much similarity between the techniques. In terms of trade-offs, our paradigms [7, 14, 15, 22, 29, 30, 31]. This foundational work pro- approach is lighter weight (temporal specifications of properties vides a starting point from which one can begin to analyze the prop- are unnecessary) and more modular (changing pointcut designators erties of aspect-oriented programs, develop principled new pro- used by advice does not necessitate re-type checking the mainline gramming features, study verification techniques and derive useful program), but checks a much coarser-grained property (we guaran- type systems. In this paper, our semantic foundations were derived tee that all functional properties of advice are preserved). Having directly from earlier work by Walker, Zdancewic and Ligatti [30]. said that, it certainly seems possible to combine these two different The main novelty with respect to this earlier research is the devel- ideas in a single system, an interesting idea for future research. opment of a type system for ensuring that aspects do not interfere Another interesting line of current research involves finding with each other or the mainline computation. ways to add aspect-oriented programming features to languages Clifton and Leavens [3] proposed techniques for Hoare-style with module systems, or vice-versa. One of the first systems to assistants ob- reasoning about aspect-oriented programs using and combine aspects and modules effectively was Lieberherr, Lorenz servers . Our notion of harmless advice is similar to their notion and Ovlinger’s Aspectual Collaborations [21, 24]. Their proposal of observers — observers do not interfere with the mainline com- allows module programmers to choose the join points (i.e., control- putation. However, the details of our type and effect system are flow points) that they will expose to external advice. External ad- entirely different from their Hoare logic. One point of interest is vice cannot intercept control-flow points that have not been ex- that Clifton and Leavens mention that it is not clear whether their posed. Aldrich [1] has proposed another model for combining as- model can “accommodate dynamic context join points like CFlow.” pects and modules called Open Modules. Open Modules have a spe- Our analysis of our stack operations, which are sufficient for coding cial module sealing operator that hides internal control-flow points up CFlow-like primitives, indicates that harmless advice can indeed from external advice. Aldrich has used logical relations to show safely use these primitives and avoid interfering with the mainline that sealed modules have a powerful implementation-independence computation or each other. property.The current report differs from this previous research as it Rinard, Salcianu, and Bugrara [26] developed a system that does not suggest that visibility of the interception points be limited; classifies the interaction between aspects and main program code instead, we suggest limiting the capabilities of advice. Once again, into five categories: orthogonal (aspects and main program code it seems quite likely that one could combine both ideas. Sullivan, have no fields in common), independent (aspects and main program et al. [28] present a case study transforming crosscutting concerns code cannot write to fields that the other can access), observation in an overlay network application into aspects. Based on their ex- (aspects can read fields that the main program code writes), actua- perience, they propose a software engineering technique where the tion (aspects can write to fields that the main program code reads), mainline code programmer is aware of locations in their code that and interference (aspects and main program code can write to the might be requested to trigger future common crosscutting concerns same fields) interactions. Our definition of harmlessness would in- and takes care to allow access for aspect programmers to the corre- clude Rinard, et al.’s orthogonal, independent, and observation in- sponding pointcuts. As in Aldrich’s work, this allows the mainline teractions. Their tool uses a variety of data flow and control flow module code to change without disrupting the aspects. Kiczales and analyses and operates within Java’s nominal type structure, so the Mezini [18], rather than restricting aspects’ influence on a module, details of their system are quite different from our own. In addi- have proposed a new method of modular reasoning in the presence tion, their system is described informally in English; they have not of aspects. To determine the interface to a module in their system, proven any properties of their analyses. the entire program must be examined—an aspect-aware module in- Katz [16] also describes several categories of advice, including terface also lists all aspects that are triggered by the module. “almost spectative” advice. “Almost spectative” advice is similar to Finally, together with Washburn and Weirich [5], we have our notion of harmless advice in that it may halt execution but does shown how to extend the core calculus and a related functional not otherwise influence the result of the program. He then specu- source language with polymorphic functions, polymorphic advice lates on several potential methods to categorize advice, including and run-time type analysis. In the future, we are planning to merge regression testing, proofs by induction, and dataflow analysis. these two efforts in order to support safe but flexible type-directed Douence, Fradet and Sudholt¨ [6] analyze aspects defined by re- aspect-oriented programming. cursion together with parallel and sequencing combinators. They develop a number of formal laws for reasoning about their combi- nators and an algorithm that is able to detect strong independence. 5. Conclusions W. Griswold. An overview of AspectJ. In European Conference on Object-oriented Programming. Springer-Verlag, 2001. In this paper, we have investigated the idea of harmless advice: aspect-oriented advice that does not interfere with the mainline [18] G. Kiczales and M. Mezini. Aspect-oriented programming and computation. While strictly less powerful than ordinary advice, we modular reasoning. In ICSE '05: Proceedings of the 27th international believe that harmless advice can be used in many contexts including conference on Software engineering, pages 49–58, New York, NY, USA, 2005. ACM Press. security monitoring, profiling, logging, and for some debugging tasks. Harmless advice has the advantage that it may be added to [19] M. Kim, M. Viswanathan, H. Ben-Abdallah, S. Kannan, I. Lee, and a program after-the-fact, in the typical aspect-oriented style, yet O. Sokolsky. Formally specified monitoring of temporal properties. programmers do not have to worry about it corrupting important In European Conference on Real-time Systems, York, UK, June 1999. mainline data invariants and hence they retain the ability to perform [20] S. Krishnamurthi, K. Fisler, and M. Greenberg. Verifying aspect local reasoning about partial correctness of their programs. advice modularly. In Foundations of Software Engineering, Oct.-Nov. 2004. References [21] K. J. Lieberherr, D. Lorenz, and J. Ovlinger. Aspectual collaborations – combining modules and aspects. The Computer Journal, 46(5):542– [1] J. Aldrich. Open modules: Modular reasoning about advice. In 565, September 2003. European Conference on Object-Oriented Programming, pages 144– 168, July 2005. [22] H. Masuhara, G. Kiczales, and C. Dutchyn. Compilation semantics of aspect-oriented programs. In G. T. Leavens and R. Cytron, editors, [2] L. Bauer, J. Ligatti, and D. Walker. Composing security policies in Foundations of Aspect-Oriented Languages Workshop, pages 17–25, polymer. In ACM Conference on Programming Language Design and Apr. 2002. Implementation, June 2005. [23] A. Myers and B. Liskov. Jflow: Practical mostly-static information [3] C. Clifton and G. T. Leavens. Observers and assistants: A proposal flow control. In Twenty-Sixth ACM Symposium on Principles of for modular aspect-oriented reasoning. In Foundations of Aspect Programming Languages, pages 226–241, Jan. 1998. Languages, Apr. 2002. [24] J. Ovlinger. Modular Programming with Aspectual Collaborations. [4] A. Colyer and A. Clement. Large-scale AOSD for middleware. In PhD thesis, Northeastern University, 2003. Proceedings of the 3rd international conference on Aspect-oriented ACM software development, pages 56–65. ACM Press, 2004. [25] F. Pottier and V. Simonet. Information flow inference for ML. Transactions on Programming Languages and Systems, 25(1):117– [5] D. S. Dantas, D. Walker, G. Washburn, and S. Weirich. PolyAML: 158, Jan. 2003. a polymorphic aspect-oriented functional programming language. In ICFP '05: Proceedings of the tenth ACM SIGPLAN international [26] M. Rinard, A. Salcianu, and S. Bugrara. A classification system SIGSOFT '04/FSE- conference on Functional programming, pages 306–319, New York, and analysis for aspect-oriented programs. In 12: Proceedings of the 12th ACM SIGSOFT twelfth international NY, USA, 2005. ACM Press. symposium on Foundations of software engineering, pages 147–158, [6] R. Douence, P. Fradet, and M. Sudholt.¨ Composition, reuse and New York, NY, USA, 2004. ACM Press. interaction analysis of stateful aspects. In AOSD '04: Proceedings of the 3rd international conference on Aspect-oriented software [27] A. Sabelfeld and A. C. Myers. Language-based information-flow IEEE Journal on Selected Areas in Communications, 21(1), development, pages 141–150, New York, NY, USA, 2004. ACM security. 2003. Press. , 21(1):5–19, 2003. [7] R. Douence, O. Motelet, and M. Sudholt.¨ A formal definition [28] K. Sullivan, W. G. Griswold, Y. Song, Y. Cai, M. Shonle, N. Tewari, of crosscuts. In Third International Conference on Metalevel and H. Rajan. Information hiding interfaces for aspect-oriented ESEC/FSE-13: Proceedings of the 10th European software architectures and separation of crosscutting concerns, volume 2192 design. In engineering conference held jointly with 13th ACM SIGSOFT of Lecture Notes in Computer Science, pages 170–186, Berlin, Sept. international symposium on Foundations of software engineering 2001. Springer-Verlag. , pages 166–175, New York, NY, USA, 2005. ACM Press. [8] Ulf´ ar. Erlingsson and F. B. Schneider. IRM enforcement of Java [29] D. B. Tucker and S. Krishnamurthi. Pointcuts and advice in higher- stack inspection. In IEEE Symposium on Security and Privacy, pages Proceedings of the 2nd International Conference 246–255, Oakland, California, May 2000. order languages. In on Aspect-Oriented Software Development, pages 158–167, 2003. [9] D. Evans. Policy-Directed Code Safety. PhD thesis, MIT, 1999. [30] D. Walker, S. Zdancewic, and J. Ligatti. A theory of aspects. In [10] D. Evans and A. Twyman. Flexible policy-directed code safety. In ACM International Conference on Functional Programming, Uppsala, IEEE Security and Privacy, Oakland, CA, May 1999. Sweden, Aug. 2003. [11] R. E. Filman and D. P. Friedman. Aspect-oriented programming is [31] M. Wand, G. Kiczales, and C. Dutchyn. A semantics for advice quantification and obliviousness. In R. E. Filman, T. Elrad, S. Clarke, and dynamic join points in aspect-oriented programming. ACM and M. Aks¸it, editors, Aspect-Oriented Software Development, pages Transactions on Programming Languages and Systems, 26(5):890– 21–35. Addison-Wesley, Boston, 2005. 910, 2004. [12] R. Harper and C. Stone. A type-theoretic interpretation of Standard ML. In Proof, Language and Interaction: Essays in Honour of Robin Acknowledgments Milner. The MIT Press, 1998. We would like to thanks Geoff Washburn for suggesting we translate the [13] List of main users. AspectJ Users List: [email protected], source language in Core2 as a way to establish source language aspects are June 2004. Requires subscription to access archives. harmless. We would also like to thank Geoff, Stephanie Weirich and Steve [14] R. Jagadeesan, A. Jeffrey, and J. Riely. A calculus of typed aspect- Zdancewic for stimulating discussions on aspects and related topics. oriented programs. Unpublished manuscript., 2003. [15] R. Jagadeesan, A. Jeffrey, and J. Riely. A calculus of untyped aspect- oriented programs. In European Conference on Object-Oriented Programming, Darmstadt, Germany, July 2003. [16] S. Katz. Diagnosis of harmful aspects using regression verification. In Foundations of Aspect-Oriented Languages, Mar. 2004. [17] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, and A. Core2 Extensions to Core1 A.7 Store Access (new, upd, read)
0 0 A.1 Core2 Grammar new0 v = v upd0 v v = v read0 v = v 0 0 e ::= ... | p
A.2 Core2 Expression Typing readi S(l) 6= void A[[|A|i]]l[v] = e 0 0 (S, A, p, l[v]) 7−→ (S, A, p, e) Γ; p `2 e1 : unit Γ; p `2 e2 : unit i β i 0 0 p ∈ H p ∈ L `2 p ≤ p (r ∈/ S) (S, A, p, refp0 v)i 7−→β2 ((S, r = newi v), A, p, r)i 0 Γ; p `2 p
~ dom(S)= dom(Γ) ∀r ∈ dom(S). Γ `2 S(r)⇒ Γ(r) l ∈ {l}p0 A[[A]]l[v] = e ∀l ∈ dom(S). `2 S(l) ⇒ Γ(l) ~ 0 0 A[[<{{l}p0 .x →p e }|void>, A]]l[v] = p
l ∈ {~l} 0 A[[A]] = e A.4 Aspect Store Typing p l[v] 0 0 A[[
0 0 0 DEFINITION A.3 (|A|i). (S, A, p, e) 7−→ (S , A , p, e ) 0 0 0 | · |i = · |A, v|i = |A|i, |v|i (S, A, p, e) 7−→top (S , A , p, e ) |A,
exp val 0 0 P ; Γ ` v : τ =⇒ v Γ(x)= τ P ; Γ; p ` e1 : string =⇒ e1 dec 0 exp exp P ; Γ, x : string; p ` as; asps; e2 : τ =⇒ e P ; Γ; p ` v : τ =⇒ v0 P ; Γ; p ` x : τ =⇒ x 2 dec 0 0 1 asps 2 exp 0 exp 0 P ; Γ; p ` (string x = e )as; ; e : τ =⇒ let x = e1 in e2 P ; Γ; p ` e1 : unit =⇒ e1 P ; Γ; p ` e2 : τ =⇒ e2 exp exp 0 0 0 1 P ; Γ; p ` e1; e2 : τ =⇒ e1; e2 P ; Γ; p ` e : bool =⇒ e1 dec 0 P ; Γ, x : bool; p ` as; asps; e2 : τ =⇒ e2 exp P ; Γ; p ` e : string =⇒ e0 dec 0 0 1 asps 2 exp P ; Γ; p ` (bool x = e )as; ; e : τ =⇒ let x = e1 in e2 P ; Γ; p ` print e : unit =⇒ print e0 0 exp 0 1≤i≤n (P ;(Γ, x : τself , y : τi); p ` ei : τi =⇒ ei) exp 0 1 P ; Γ; p ` e1 : bool =⇒ e1 0 ..n (P,(o.mi : (τself , τi, τi , p)) );(Γ, o : τself ); p ` exp 0 exp 0 P ; Γ; p ` e2 : τ =⇒ e2 P ; Γ; p ` e3 : τ =⇒ e3 dec 0 as; asps; e2 : τ =⇒ e2 exp 0 0 0 1 P ; Γ; p ` if e1 then e2 else e3 : τ =⇒ if e then e else e 0 ..n 1 2 3 P ; Γ; p ` (object o = [mi : τi = ς xi.λyi : τi.ei] ) dec as; asps; e2 : τ =⇒ dec 0 P ; Γ; p ` ds; .; e : τ =⇒ e let om1,pre = newp : (τself , τ1, string)in ... exp 0 let omn,pre = newp : (τself , τn, string)in P ; Γ; p ` let ds in e : τ =⇒ e 0 let om1,post = newp : (τself , τ1, string)in ... 0 1..n exp 0 0 let omn,post = newp : (τself , τn, string)in P ; Γ; p ` e1 : [mi:p τi] =⇒ e1 τj = τ →p τ i let o = [mi = ςp xi.λpyi : τi. exp 0 2 00 P ; Γ; p ` e : τ =⇒ e2 ` pj = p store omi,pre[(xi, yi, “o.mi )] in 0 exp 0 0 omi,pre[(xi, yi, “o.mi“)]; P ; Γ; p ` e1.mj(e2): τ =⇒ e1.mj e2 0 let resi = ei in omi,post[(xi, resi, “o.mi“)]; exp 0 0 P ; Γ; p ` e : τ refp0 =⇒ e ` p ≤ p resi 1..n 0 exp 0 ] in e2 P ; Γ; p `! e : τ =⇒! e 0 1..n where τself = [mi:pτi →p τi ] exp 0 exp 0 0 P ; Γ; p ` e1 : τ refp0 =⇒ e1 P ; Γ; p ` e2 : τ =⇒ e2 ` p ≤ p exp 0 P ; Γ; p ` e1 : τ =⇒ e1 exp 0 0 0 dec 0 P ; Γ; p ` e1 := e2 : unit =⇒ e1 := e2 P ; Γ, x : τ refp; p ` as; asps; e2 : τ =⇒ e2
0 dec exp 0 pat 0 0 P ; Γ; p ` (ref x = e1)as; asps; e2 : τ =⇒ P ; Γ; p ` e1 : stack =⇒ e1 P ; p ` pat =⇒ pat a Γ ; Θ 0 0 0 exp 0 exp 0 let x = refp e1 in e2 P ; Γ, Γ ; p ` e2 : τ =⇒ e2 P ; Γ; p ` e3 : τ =⇒ e3 exp (1≤i≤n) P ; Γ; p ` case e1 of(pat ⇒ e2 | ⇒ e3): τ =⇒ (P(o.mi)= (τself , τarg , τres, pi)) 0 0 0 0 case e1 of(pat ⇒ split(Θ, e2) | ⇒ e3) P ;(Γ, x : τself , y : τarg , s : stack, n : string); p ` exp 0 e1 : unit =⇒ e1 ` p ≤ pi dec 0 B.3 Split Function P ; Γ; p ` as; asps; e2 : τ =⇒ e2
split(·, e) = e dec split(a → (x, y, z), Θ)= split(Θ, split(x, y, z)= a in e) P ; Γ; p ` (before {o.m~ }(x, y, s, n) = e1) as; asps; e2 : τ =⇒ ⇑ {{om~pre}p.z →p split(x, y, n) = z in let s = stack()in e0 }; e0 B.4 Theta Translation 1 2 1 (P(o.m ) = (τ , τ , τ , p ))( ≤i≤n) Γ a · ⇒ Γ i self arg res i P ;(Γ, x : τself , y : τres, s : stack, n : string); p ` 0 exp 0 Γ a Θ ⇒ Γ e1 : unit =⇒ e1 ` p ≤ pi 0 00 0 0 00 dec 0 Γ, x : τ, y : τ , z : τ a Θ, z → (x, y, z) ⇒ Γ , z : (τ × τ × τ ) P ; Γ; p ` as; asps; e2 : τ =⇒ e2
dec B.5 Pattern Translation P ; Γ; p ` (after {o.m~ }(x, y, s, n) = e1) as; asps; e2 : τ =⇒ ⇑ {{om~post}p.z →p (1≤i≤n) split( ) in let stack()in 0 0 (P(o.mi) = (τself , τarg , τres, pi)) x, y, n = z s = e1}; e2 pat 0 0 P ; p ` pat =⇒ pat a Γ ; Θ B.7 Program Translation pat 0 P ; p ` {o.m~ }[x, y, n] :: pat =⇒ {om~pre}p[z] :: pat : dec 0 asps 0 (Γ , x : τself , y : τarg , n : string; Θ, z → (x, y, n)) .; .; main ` ds; ; e : τ =⇒ e prog ` ds asps e : τ =⇒ e0 pat P ; p ` nil =⇒ nil a ·; ·
pat P ; p ` pat =⇒ pat0 a Γ0; Θ pat P ; p ` :: pat =⇒ :: pat0 a Γ0; Θ