An idealized MetaML: Simpler, and more expressive (includes proofs)

An Idealized MetaML: Simpler, and More Expressive? . (Includes Proofs) Eugenio Moggi1, Walid Taha2, Zine El-Abidine Benaissa2 , and Tim Sheard2 1 DISI, Univ di Genova Genova, Italy [email protected] 2 Oregon Graduate Institute Portland, OR, USA fwalidt,benaissa,[email protected] Abstract. MetaML is a multi-stage functional programming language featuring three constructs that can be viewed as statically-typed re nements of the back-quote, comma, and eval of Scheme. Thus it provides special support for writing code generators and serves as a semanticallysound basis for systems involving multiple interdependent computational stages. In previous work, we reported on an implementation of MetaML, and on a small-step semantics and type-system for MetaML. In this paper, we present An Idealized MetaML (AIM) that is the result of our study of a categorical model for MetaML. An important outstanding problem is nding a type system that provides the user with a means for manipulating both open and closed code. This problem has eluded e orts by us and other researchers for over three years. AIM solves the issue by providing two type constructors, one classi es closed code and the other open code, and exploiting the way they interact. 1 Introduction \If thought corrupts language, language can also corrupt thought"1 . Staging com- putation into multiple steps is a well-known optimization technique used in many important algorithms, such as high-level program generation, compiled program execution, and partial evaluation. Yet few typed programming languages allow us to express staging in a natural and concise manner. MetaML was designed to ll this gap. Intuitively, MetaML has a special type for code that combines some The research reported in this paper was supported by the USAF Air Materiel Command, contract #F19628-96-C-0161, NSF Grant IRI-9625462, DoD contract \Domain Speci c Languages as a Carrier for Formal Methods", MURST progetto co nanziato \Tecniche formali per la speci ca, l'analisi, la veri ca, la sintesi e la trasformazione di sistemi software", ESPRIT WG APPSEM 1 George Orwell, Politics and the English Language, 1946. ? features of both open code, that is, code that can contain free variables, and that is, code that contains no free variables. In a statically typed setting, open code and closed code have di erent properties, which we explain in the following section. closed code, Open and Closed Code A number of typed languages for manipulating code fragments have been proposed in the literature. Some have types for open code [9,6,3, 12], and others have types for closed code [4,13]. On one hand, languages with open code types play an important role in the study of partial evaluation. Typically, they provide two constructs, one for building a code fragment with free variables, and one for combining such fragments. Being able to construct open fragments allows the user to force computations \under a lambda". Generally, it has been hard for such languages to include constructs for executing such code fragments, because they can contain \not-yet-bound identi ers". On the other hand, languages with closed code types play an important role in the study of run-time (machine) code generation. Typically, they include constructs for building closed code, and for executing them. Generally, in such languages there is no mechanism for forcing computations \under a lambda". The importance of having a way to execute code within a language is best illustrated by considering the eval of Scheme. In particular, Ecient implementations of Domain-Speci c or \little" languages can be developed as follows: First, build a translator from the source language to Scheme, and then use eval to execute the generated Scheme code. For many languages, such an implementation would be almost as simple as an interpreter implementation (especially if back-quote and comma are utilized), but would incur almost non of the overhead associated with an interpretive implementation. MetaML [12,11] provides constructs for manipulating open code and executing it, but does not distinguish between open and closed code types. But open code cannot be executed because it may contain free variables that have not been bound yet. This means that in MetaML type information is not enough to decide whether or not we can safely execute a code fragment. In what follows, we introduce MetaML, explain what it allows us to express, and where it falls short. MetaML MetaML has three staging annotations: Brackets h i, Escape ~ and Run run . An expression hei defers the computation of e; ~ e splices the deferred expression obtained by evaluating e into the body of a surrounding Bracketed expression; and run e evaluates e to obtain a deferred expression, and then evaluates it. Note that ~e is only legal within lexically enclosing Brackets. Finally, Brackets in types such as <int> are read \Code of int". To illustrate, consider the following interactive session: -| val rec exp = fn n => fn x => if n=0 then <1> else < ~x * ~(exp (n-1) x) >; val exp = fn : int -> <int> -> <int> -| val exponent = fn n => <fn a => ~(exp n <a>)>; val exponent = fn : int -> <int -> int> -| val cube = exponent 3; val cube = <fn a => a * (a * (a * 1))> : <int -> int> -| val program = <~cube 2> val program = <(fn a => a * (a * (a * 1))) 2> : <int> -| run program; val it = 8 : int The function exp returns a code fragment representing an exponent, given an integer power n and a code fragment representing a base x. The function exponent is very similar, but takes only a power and returns a code fragment representing a function that takes a base and returns the exponent. The code fragment cube is the specialization of exponent to the power 3. Next, we construct the code fragment program which is an application of the code of cube to the base 2. Finally, the last declaration executes this code fragment. Unfortunately, there is a problem with the above example. In particular, the very last declaration is not typable with the basic type system of MetaML [11]. Intuitively, the type system for MetaML must keep track of free variables in a code fragment, so as to ensure that programs don't get stuck. But there is no way for the type system to know that program is closed, hence, a conservative approximation is made, and the term is rejected by the type system. Contribution and Organization of this Paper In previous work [12], we reported on the implementation and applications of MetaML, and later [11] presented an axiomatic semantics and a type system for MetaML and proved type-safety. However, there were still a number of drawbacks: 1. As discussed above, there is a typing problem with executing a separatelydeclared code fragment. While this problem is addressed in the implementation using a sound rule for top-level declarations, this solution is ad hoc. 2. Only a call-by-value semantics could be de ned for MetaML, because substitution was a partial function, only de ned when variables are substituted with values. 3. The type judgment used two indices. Moreover, it has been criticized for not being based on a standard logical system [13]. This paper describes the type system and operational semantics of An Idealized MetaML (AIM), whose design is inspired by a categorical model for MetaML (such a model will be the subject of another paper). AIM is strictly more expressive than any known typed multi-level language, and features: 1. An open code type hti, which corresponds to t of  [3] and hti of MetaML; 2. A closed code type [t], which corresponds to t of  [4]; 3. Cross-stage persistence of MetaML; 4. A Run-with construct, generalizing Run of MetaML. This work is the rst to achieve a semantically sound integration of Davies and Pfenning's  [4] and Davies'  [3], and to identify useful interactions between them. Moreover, we present important simpli cations over MetaML [11], which overcome the problems mentioned above: 1. The type system uses only one level annotation, like the  type system [3]; 2. The level Promotion and level Demotion lemmas, and the Substitution lemma, are proven in full generality and not just for the cases restricted to values. This development is crucial for a call-by-name semantics. Such a semantics seems to play an important role in the formal theory of Normalization by Evaluation [1] and Type Directed Partial Evaluation [2]; 3. The big-step semantics is de ned in the style in which  was de ned [3], and does not make explicit use of a stateful renaming function; 4. Terms have no explicit level annotations. Finally, it is straight forward to extend AIM with new base types and constants, therefore it provides a general setting for investigating staging combinators. In the rest of the paper, we present the type system and establish several syntactic properties. We give a big-step semantics of AIM, including a call-by-name variant, and prove type-safety. We present embeddings of  , MetaML and  into AIM. Finally, we discuss related works. 2 AIM: An Idealized MetaML The de nition of AIM's types t 2 T and terms e 2 E is parameterized with respect to a signature consisting of a set of base types b and constants c: t 2 T: : = b j t1 ! t2 j hti j [t] e 2 E: : = c j x j e1 e2 j x:e j hei j ~e j run e with fx = e ji 2 mg j box e with fx = e ji 2 mg j unbox e i i i i Where m is a natural number, and it is identi ed with the set of its predecessors. The rst four constructs are the standard ones in a call-by-value -calculus with constants. Bracket and Escape are the same as in MetaML [12,11]. Run-With generalizes Run of MetaML, in that allows the use of additional variables x in the body of e if they satisfy certain typing requirements that are made explicit in the next section. Box-With and unbox are not in MetaML, but are motivated by  of Davies and Pfenning [4]. We use some abbreviated forms: run e for run e with ; box e for box e with ; run e with x = e for run e with fx = e ji 2 mg box e with x = e for box e with fx = e ji 2 mg i i i i i i i i i ?; x: tn1 ` e: tn2 ? ` x:e: (t1 ! t2 )n ? ` e: htin ? ` e: tn+1 ? ` e1 : (t1 ! t2 )n ? ` e2 : tn1 ? ` e1 e2 : tn2 ? ` hei: htin ? ` ~e: tn+1 ? ` ei : [ti ]n ? +1 ; fxi : [ti ]n ji 2 mg ` e: htin ? ` run e with xi = ei : tn ? ` e: [t]n ? ` ei : [ti ]n fxi : [ti ]0 ji 2 mg ` e: t0 n ? ` box e with xi = ei : [t] ? ` unbox e: tn ? ` c: tnc ? ` x: tn if ? x = tm and m  n Fig. 1. Typing Rules 2.1 Type System An AIM typing judgment has the form ? ` e: tn , where t 2 T, n 2 N and ? is a type assignment, that is, a nite set fxi: tni ji 2 mg with the xi distinct. The reading of ? ` e: tn is \term e has type t at level n in the type assignment ? ". We say that ? x = tn if x: tn is in ?. Furthermore, we write ? +r for the type assignment obtained by incrementing the level annotations in ? by r, that is, ? +r x = tn+r if and only if ? x = tn . Figure 1 gives the typing rules for AIM. The Constant rule says that a constant c of type tc , which has to be given in the signature, can be used at any level n. The Variable rule incorporates cross-stage persistence, therefore if x is introduced at level m it can be used later, that is, at level n  m, but not before. The Abstraction and Application rules are standard. The Bracket and Escape rules establish an isomorphism between tn+1 and htin . Typing Run in MetaML [11] introduces an extra index-annotation on types for counting the number of Runs surrounding an expression (see Figure 3). We avoid this extra annotation by incrementing the level of all variables in ?. In particular, the Run rule of MetaML becomes i ? +1 ` e: htin ? ` run e: tn The Box rule ensures that there are no \late" free variables in the term being Boxed. This ensures that when a Boxed term is evaluated in a type-safe context, the resulting value is a closed term. The Box rule ensures that only the variables explicitly bound in the Box statement can occur free in the term e. At the same time, it ensures that no \late" free variable can in ltrate the body of a Box using one of these variables. This is accomplished by forcing the With-bound variables themselves to have a Boxed type. Note that in run e with xi = ei the term e may contain other free variables besides the xi . 2.2 Properties of the Type System The following level Promotion, level Demotion and Substitution lemmas are needed for proving Type Preservation. Lemma 1 (Promotion). If ?1; ?2 ` e: t n then ?1; ?2+1 ` e: tn+1 . Meaning that if we increment the level of a well-formed term e it remains wellformed. Furthermore, we can simultaneously increment the level of an arbitrary subset of the variables in the environment. Demotion on e at n, written e # , lowers the level of e from level n + 1 down to level n, and is well-de ned on all terms, unlike demotion for MetaML [11]. n De nition 1 (Demotion). e # n is de ned by induction on e: c #n=c x #n=x (e1 e2 ) #n=e1 #n e2 #n (x:e) #n=x:e #n hei #n =he #n+1i ~e #0 =run e (~e) #n+1 =~(e #n) (run e with xi = ei ) #n=run e #n with xi = ei #n (box e with xi = ei ) #n=box e with xi = ei #n (unbox e) #n =unbox e #n The key for making demotion total on all terms is handling the case for Escape Escape is simply replaced by Run. It should also be noted that demotion does not go into the body of Box. ~ e #0 : Lemma 2 (Demotion). If ? +1 ` e: t +1 then ? ` e #n: tn. n Meaning that demotion of a well-formed term e is well-formed, provided the level of all free variables is decremented. Details of all proofs can be found in the Appendix. Lemma 3 (Weakening). If ?1; ?2 ` e2 : t2 n e2: tn2 . Lemma 4 (Substitution). If ?1 ` e1 : t1 e2[x: = e1 ]: tn2 . 0 n and x is fresh, then ?1; x: t1 ; ?2 ` n 0 and ?1; x: tn1 ; ?2 ` e2 : tn2 then ?1 ; ?2 ` 0 This is the expected substitution property, that is, a variable x can be replaced by a term e1 , provided e1 meets the type requirements on x. Evaluation. 0 0 0 e1 ,! x:e e2 ,! v1 e[x:= v1 ] ,! v2 0 e1 e2 ,! v2 0 x:e ,! x:e 0 0 0 ei ,! vi e[xi: = vi] ,! hv0 i v0 #0 ,! v 0 run e with xi = ei ,! v 0 e ,! hvi 1 ~ e ,! v 0 ei ,! vi 0 box e with xi = ei ,! box e[xi: = vi] 0 0 e ,! box e0 e0 ,! v 0 unbox e ,! v Building. n+1 e ,! v n+1 unbox e ,! unbox v n+1 e ,! v n+1 x:e ,! x:v n+1 x ,! x n+1 ei ,! vi n+1 run e with xi = ei ,! run v with xi = vi n+1 e ,! v n+2 ~ e ,! ~ v n+1 e ,! v n hei ,! hvi n+1 ei ,! vi n+1 box e with xi = ei ,! box e with xi = vi n+1 n+1 e1 ,! v1 e2 ,! v2 n+1 e1 e2 ,! v1 v2 n+1 c ,! c 0 e1 ,! v 6 x:e 0 e1 e2 ,! err 0 x ,! err 0 e ,! v 6 he0 i 1 ~e ,! err ~e ,! err n+1 e ,! v Stuck. 0 e ,! v 6 box e0 0 unbox e ,! err 0 0 ei ,! vi e[xi: = vi] ,! v 6 he0 i 0 run e with xi = ei ,! err Fig. 2. 0 Big-Step Semantics 3 Big-Step Semantics The big-step semantics for MetaML [12] re ects the existing implementation: it is complex, and hence not very suitable for formal reasoning. Figure 2 presents a concise big-step semantics for AIM, which is presented at the same level of abstraction as that for  [3]. We avoid the explicit use of a gensym or newname for renaming bound variables: this is implicitly done by substitution. De nition 2 (Values). v0 2 V 0 : : = x:e j hv1 i j box e v1 2 V 1 : : = c j x j v1 v1 j x:v1 j hv2 i j run v1 with x = v1 j box e with x = v1 j unbox v1 v +2 2 V +2 : : = c j x j v +2 v +2 j x:v +2 j hv +3 i j ~v +1 j run v +2 with x = v +2 j box e with x = v +2 j unbox v i i n n n n i i n n i n n i n n i i +2 n Values have three important properties: First, a value at level 1 can be a Bracketed or a Boxed expression, re ecting the fact that terms representing open and closed code are both considered acceptable results from a computation. Second, values at level n + 1 can contain Applications such as h(y:y) (x:x)i, re ecting the fact that Brackets defer computations. Finally, there are no level 1 Escapes in values, re ecting the fact that having such an Escape in a term would mean that evaluating the term has not yet been completed. This is true, for example, in terms like h~(f x)i. Lemma 5 (Orthogonality). If v 2 V 0 and ? ` v: [t]0 then ; ` v: [t]0 . Theorem 1 (Type Preservation). If ? +1 ` e: t and e ,! v then v 2 V and ? +1 ` v: t . Note that in AIM (unlike ordinary programming languages) we cannot restrict the evaluation rules to closed terms, because at levels above 0 evaluation is symbolic and can go inside the body of binders. On the other hand, evaluation of a variable at level 0 is an error! The above theorem strikes the right balance, namely it allows open terms provided their free variables are at level above 0 (this is re ected by the use of ? +1 in the typing judgment). Having no level 1 escapes ensures that demotion is the identity on V +1 as shown in following lemma. Thus, we don't need to perform demotion in the evaluation rule for Run when evaluating a well-formed term. n n n n n Lemma 6 (Value Demotion). If v 2 V +1 then v #n  v. n A good property for multi-level languages is the existence of a bijection between programs ; ` e: t0 and program representations ; ` hvi: hti0 . This property holds for AIM, in fact it is a consequence of the following result: Proposition 1 (Re ection). If ? ` e: t , then ? +1 ` e: t +1 and e 2 V +1 . Conversely, if v 2 V +1 and ? +1 ` v: t +1 , then ? ` v: t . n n n 3.1 Call-by-Name n n n The di erence between the call-by-name semantics and the call-by-value semantics for AIM is only in the evaluation rule for Application at level 0. For call-byname, this rule becomes 0 0 e1 ,! x:e e[x: = e2 ] ,! v 0 e1 e2 ,! v The Type Preservation proof must be changed for this case. However, this not problematic, since the Substitution Lemma for the AIM's type system has no value restriction. Theorem 2 (CBN Type Preservation). If ? +1 2 ` v V n and ? +1 v: tn . ` e: tn and e ,!n v then 3.2 Expressiveness MetaML's type system has one Code type constructor, which tries to combine the features of the Box and Circle type constructors of Davies and Pfenning. However, this combination leads to the typing problem discussed in the introduction. In contrast, AIM's type system incorporates both Box and Circle type constructors, thereby providing correct semantics for the following functions: 1. unbox : [t] ! t. This function executes closed code. AIM has no function of type t ! [t], thus we avoid the \collapse" of types in the recent work of Wickline, Lee, and Pfenning [13]. Such a function does not exist in MetaML. 2. up : t ! hti. This function corresponds to cross-stage persistence [12], in fact it embeds any value into an open fragment, including values of functional type. Such a function does not exist in  . At the same time, AIM has no function of type hti ! t, re ecting the fact that open code cannot be executed. up is expressible as x:hxi. 3. weaken : [t] ! hti. The composite of the two functions above. weaken re ects the fact that closed code can always be viewed as open code. AIM has no function of type hti ! [t]. 4. execute : [hti] ! t. This function executes closed code, and it can be de ned in AIM as x:run x with x = x. 5. build: [hti] ! [hti] This function forces the building of an open fragment known to be closed. build is not expressible in the language, but it can be added as a new combinator with the following semantics: !0 box e0 e0 ,!0 hvi 0 build e ,! box hvi e, Type Preservation is still valid with such an extension. Now, the MetaML example presented in the Introduction can be expressed in AIM as follows: -| val rec exp = box (fn n => fn x => if n=0 then <1> else < ~x * ~((unbox exp) (n-1) x) >) with {exp=exp}; val exp = [fn] : [int -> <int> -> <int>] -| val exponent = box (fn n => <fn a => ~((unbox exp) n <a>)>) with {exp=exp}; val exponent = [fn] : [int -> <int -> int>] -| val cube = build (box ((unbox exponent) 3) with {exponent=exponent}); val cube = [<fn a => a * (a * (a * 1))>] : [<int -> int>] -| val program = build (box <~(unbox cube) 2> with {cube=cube}) val program = [<(fn a => a * (a * (a * 1))) 2>] : [<int>] -| execute program; val it = 8 : int In AIM, asserting that a code fragment is closed (using Box) has become part of the responsibilities of the programmer. Furthermore, Build is needed to explicitly overcome the default lazy behavior of Box. If Build was not used in the above examples, the (Boxed code) values returned for cube and program would contain level 0 Escapes. In general, it appears that the lazy behavior of Box is not needed when our primary concern is high-level program generation. Unfortunately, the syntax is verbose compared to that of MetaML. In future work, we hope to improve the syntax based on experience using AIM. 4 Embedding Results This section shows that other languages for staging computations can be translated into AIM, and that the embedding respects the typing and evaluation. The languages we consider are  [3], MetaML [11], and  [4]. 4.1 Embedding of  The embedding of  into AIM is straight forward. In essence,  corresponds to the Open fragment of AIM: t 2 TOpen : : = b j t1 ! t2 j hti e 2 EOpen : : = c j x j e1 e2 j x:e j hei j ~e The translation ( ) between  and AIM is as follows: ( t) = h(t )i, (next e) = he i, and (prev e) = ~ (e ). With these identi cations the typing and evaluation rules for  are those of AIM restricted to the relevant fragment. The only exception is the typing rule for variables, which in  is simply ? ` x: tn if ? x = tn (this re ects the fact that  has no cross-stage persistence). n We write ? ` e: t and e ,! v for the typing and evaluation judgments of  , so that they are not confused with the corresponding judgments of AIM. ? ` c: (tc ; r)n ? ` x: (t;r)n if ? x = (t; p)m and m + r  n + p ? ` e1 : (t1 ! t2 ; r)n ? ` e2 : (t1 ; r)n ?; x: (t1 ; r)n ` e: (t2 ; r)n ? ` x:e: (t1 ! t2 ; r)n ? ` e1 e2 : (t2 ; r)n ? ` e: (t; r)n+1 ? ` e: (hti; r)n ? ` e: (hti; r + 1)n ? ` hei: (hti; r)n ? ` ~e: (t; r)n+1 ? ` run e: (t; r)n Fig. 3. MetaML Typing rules Proposition 2 (Temporal Type Embedding). If ? ` e: tn is derivable in  , then ? ` e : (t )n is derivable in AIM. n Proposition 3 (Temporal Semantics Embedding). If e ,! v is derivable n in  , then e ,! v is derivable in AIM. 4.2 Embedding of MetaML The di erence between MetaML and AIM is in the type system. We show that while AIM's typing judgments are simpler, what is typable in MetaML remains typable in AIM. t 2 TMetaML: : = b j t1 ! t2 j hti e 2 EMetaML: : = c j x j e1 e2 j x:e j hei j ~e j run e A MetaML's typing judgment has the form
` e: (t; r)n, where t 2 T, n; r 2 N and
is a type assignment, that is, a nite set fxi : (ti; ri)n ji 2 mg with the xi distinct. Figure 3 recalls the MetaML [11]. i De nition 3 (Acceptable Judgment). We say that a MetaML typing judgment fxi: (ti; ri)n ji 2 mg ` e: (t; r)n is acceptable if and only if 8i 2 m: ri  r. i Remark 1. A careful analysis of MetaML's typing rules shows that typing judg- ments occurring in the derivation of a judgment ; ` e: (t; r)n are acceptable: In MetaML typing rules are acceptable whenever its conclusion is acceptable, simply because the index r never decreases when we go from the conclusion of a type rule to its premise, thus, we never get an environment binding with an r higher than that of the judgment. g` Proposition 4 (MetaML Type Embedding). If fxi: (ti ; ri)n ji n2+m e: (t; r)n is acceptable, then it is derivable in MetaML if and only if fxi: ti r?r ji 2 mg ` e: tn is derivable in AIM. i i 4.3 Embedding of  i Figure 4 summarizes the language  [4]. We translate  into the Closed Syntax Types t 2 T : : = b j t1 ! t2 j t Expressions e 2 E : : = x j x:e j e1 e2 j box e j let box x = e1 in e2 Type assignments ?;
: : = fxi : ti ji 2 mg Type System
; ? ` x: t if
x = t
; ? ` x: t if ?x = t
; (?; x: t ) ` e: t
; ? ` x:e: t ! t
; ? ` e1 : t ! t
; ? ` e2 : t
; ? ` e1 e2 : t (
; x: t ); ? ` e2 : t
; ? ` e1 : t
; ? ` let box x = e1 in e2 : t
; ; ` e: t
; ? ` box e: t 0 0 0 0 Big-Step Semantics 0 e1 ,! x:e e2 ,! v e[x: = v ] ,! v e1 ; e2 ,! v e1 ,! box e e2 [x: = e] ,! v let box x = e1 in e2 ,! v 0 0 0 x:e ,! x:e ! box e ,  box e Fig. 4. Description of  fragment of AIM: t 2 TClosed : : = b j t1 ! t2 j [t] e 2 EClosed : : = c j x j e1 e2 j x:e j box e with xi = ei j unbox e Furthermore, we consider only typing judgments of the form fxi : t0i ji 2 mg ` e: t0 0 and evaluation judgments of the form e ,! v. These restrictions are possible for two reasons. If the conclusion of a typing rule is of the form fxi : t0i ji 2 mg ` e: t0 with types and terms in the Closed fragment, then also the premises of the typing rule enjoy such properties. When e is a closed term in the Closed fragment, the n 0 only judgments e ,! v that can occur in the derivation of e ,! v are such that n = 0 and e and v are closed terms in the Closed fragment. 0 0 0 0 De nition 4 (Modal Type Translation). The translation of  types is given by b = b (t1 ! t2 ) = t1 ! t2 (t) = [t] The translation of  terms depends on a set X of variables, namely those declared in the modal context
. xX = unbox x if x 2 X  X x =x if x 62 X  X  X (box e) = box e with fx = x j x 2 FV(e) \ X g (let box x = e1 in e)X = (x:eX x ) e1 X (x:e)X = x:eX (e1 e2 )X = e1 X e2X [f g Proposition 5 (Modal Type Embedding). If
; ? ` e: t is derivable in  , then [
]; ?  ` eX : t is derivable in AIM's Closed fragment, where X is the set of variables declared in
, fxi: ti ji 2 mg is fxi: ti ji 2 mg, and [fxi: ti ji 2 mg] is fxi : [ti]ji 2 mg. The translation of  into the AIM's Closed fragment does not preserve evaluation on the nose (that is, up to syntactic equality). Therefore, we need to consider an administrative reduction. De nition 5 (Box-Reduction). The !box reduction is given by the rewrite rules box e0 with xi unbox (box e) ! e = ei ; x = box e; xj = ej ! box e [x: = box e] with xi = ei ; xj = ej 0 where e is a closed term of the Closed fragment. Lemma 7 (Properties of Box-Reduction). The !box reduction on the Closed fragment satis es the following properties: { Subject Reduction, that is, ? ` e: t and e ! e imply ? ` e : t { Con uence and Strong Normalization  { Compatibility with Evaluation on closed terms, that is, e1 ,! v1 and e1 ?! box e2 imply that exists v2 s.t. v1 ?!box v2 and e2 ,! v2 . Lemma 8 (Substitutivity). Given a closed term e0 2 E the following prop0 0 erties hold: { eX [y: = e0 ]  (e[y: = e 0 ])X , provided y 62 X { eX x [x: = box e0 ] ?!box (e[x: = e0 ])X ; [f g ; Proposition 6 (Modal Semantics Embedding). If e 2 E is closed and 0  e ,! v is derivable in  , then there exists v such that e ,! v and v ?! box v . ; 0 ; 0 0 5 Related Work Multi-stage programming techniques have been used in a wide variety of settings [12], including run-time specialization of C programs [10]. Nielson and Nielson present a seminal detailed study into a two-level functional programming language [9]. This language was developed for studying code generation. Davies and Pfenning show that a generalization of this language to a multi-levellanguage called  gives rise to a type system related to a modal logic, and that this type system is equivalent to the binding-time analysis of Nielson and Nielson [4]. Intuitively,  provides a natural framework where Scheme's back-quote and eval can be present in a language. The semantics of our Box and Unbox correspond closely to those of back-quote and eval, respectively. Gomard and Jones [6] use a statically-typed two-level language for partial evaluation of the untyped -calculus. This language is the basis for many binding-time analyses. Gluck and Jrgensen study partial evaluation in the generalized context where inputs can arrive at an arbitrary number of times rather than just two (namely, specialization-time and run-time) [5], and demonstrate that binding-time analysis in a multi-level setting can be done with eciency comparable to that of two-level binding time analysis. Davies extends the Curry-Howard isomorphism to a relation between temporal logic and the type system for a multi-level language [3]. Intuitively,  provides a good framework for formalizing the presence of back-quote and comma in a statically typed language. The semantics of our Bracket and Escape correspond closely to those of back-quote and comma, respectively. Moggi [8] advocates a categorical approach to two-level languages based on indexed categories, and stresses formal analogies with a categorical account of phase distinction and module languages. References 1. U. Berger and H. Schwichtenberg. An inverse of the evaluation functional for typed {calculus. In Rao Vemuri, editor, Proceedings of the Sixth Annual IEEE Symposium on Logic in Computer Science. IEEE Computer Society Press, Loss Alamitos, 1991. 2. Olivier Danvy. Type-directed partial evaluation. In ACM Symposium on Principles of Programming Languages, pages 242{257, Florida, January 1996. New York: ACM. 3. Rowan Davies. A temporal-logic approach to binding-time analysis. In Proceedings, 11th Annual IEEE Symposium on Logic in Computer Science, pages 184{195, New Brunswick, New Jersey, July 1996. IEEE Computer Society Press. 4. Rowan Davies and Frank Pfenning. A modal analysis of staged computation. In 23rd Annual ACM Symposium on Principles of Programming Languages (POPL'96), St.Petersburg Beach, Florida, January 1996. 5. Robert Gluck and Jesper Jrgensen. An automatic program generator for multilevel specialization. Lisp and Symbolic Computation, 10(2):113{158, 1997. 6. Carsten K. Gomard and Neil D. Jones. A partial evaluator for the untyped lambda calculus. Journal of Functional Programming, 1(1):21{69, January 1991. 7. Robert Harper, Furio Honsell, and Gordon Plotkin. A framework for de ning logics. Journal of the ACM, 40(1):143{184, January 1993. 8. Eugenio Moggi. A categorical account of two-level languages. In MFPS 1997, 1997. 9. Flemming Nielson and Hanne Rijs Nielson. Two-Level Functional Languages. Number 34 in Cambridge Tracts in Theoretical Computer Science. Cambridge University Press, 1992. 10. Calton Pu, Andrew Black, Crispin Cowan, and Jonathan Walpole. Microlanguages for operating system specialization. In Proceedings of the SIGPLAN Workshop on Domain-Speci c Languages, Paris, January 1997. 11. Walid Taha, Zine-El-Abidine Benaissa, and Tim Sheard. Multi-stage programming: Axiomatization and type-safety. In 25th International Colloquium on Automata, Languages, and Programming, Aalborg, Denmark, 13{17July 1998. 12. Walid Taha and Tim Sheard. Multi-stage programming with explicit annotations. In Proceedings of the ACM-SIGPLAN Symposium on Partial Evaluation and semantic based program manipulations PEPM'97, Amsterdam, pages 203{217. ACM, 1997. 13. Philip Wickline, Peter Lee, and Frank Pfenning. Run-time code generation and Modal-ML. In Proceedings of the ACM SIGPLAN'98 Conference on Programming Language Design and Implementation (PLDI), pages 224{235, Montreal, Canada, 17{19 June 1998. A Type preservation Convention 6 (Notation for Proofs on Derivations) Whenever convenient, proofs will be laid out in 2-dimensions to re ect that we are relating one derivaR tion tree to another. Symbols such as R *, () , and R + will be used for (one- or two-way) implications, where R is the list of rule(s) used to achieve this implication. Proofs start from the left and proceed either up, down, or right. We go up or down depending on the normal orientation of the particular rule that is being used in an implication. Horizontal implications are aligned with their precedents and antecedents. Lemma 1 If ?1; ?2 ` e: tn then ?1; ?2+1 ` e: tn+1. By structural induction over the rst derivation. Proof: { Lambda abstraction: `* ?1; (?2; x: t1n ) ` e: t2 n =IH ) ?1; (?2+1+1; x: t1n + 1) ` e: t2 n+1 ` + n ?1; ?2 ` x:e: t1 ! t2 ?1; ?2 ` x:e: t1 ! t2 n+1 { Variables (I): ?1 x = (t; n ) ?1 x = (t; n ) =) n n =) n < n + 1 `+ ?1; ?2 ` x: tn ?1; ?2+1 ` x: tn+1 0 0 `* 0 0 { Variables (II): ?2 x = (t; n ) =+) ?2+1 x = (t; n + 1) n n =) n + 1 +1n + 1 `+ n ?1; ?2 ` x: t ?1; ?2 ` x: tn+1 0 0 `* 0 0 The rest of the cases are completely structural. { Applications: `* { Run: `* ) ?1 ; ?2+1 ` e1 : t1 ! t2 n+1 ?1; ?2 ` e1 : t1 ! t2n =IH IH ?1; ?2 ` e2 : t1n ?1 ; ?2+1 ` e2 : t1n+1 = ) `+ ?1; ?2 ` e1 e2 : t2n ?1; ?2+1 ` e1 e2 : t2n+1 ?1; ?2 ` ei : [ti ]n =IH) ?1; ?2+1 ` ei : [ti ]n+1 n n +1 +1 ?1 ; ?2 ; fxi: [ti ] g ` e: hti =IH ) ?1+1 ; ?2+2 ; fxi: [ti ]n+1 g ` e: htin+1 ` + n ?1; ?2 ` run e with xi = ei : t ?1; ?2+1 ` run e with xi = ei : tn+1 { Escape: `* { Bracket: `* ?1 ; ?2 ` e: htin =) ?1; ?2+1 ` e: htin+1 `+ ?1; ?2 ` ~e: tn+1 ?1; ?2+1 ` ~e: tn+2 IH ?1 ; ?2 ` e: tn+1 =) ?1; ?2+1 ` e: tn+2 ` + ?1; ?2 ` hei: htin ?1; ?2+1 ` hei: htin+1 IH { Box: ?1 ; ?2 ` ei : [ti ]n ?1; ?2+1 ` ei : [ti ]n+1 = ) fxi : [ti]0 g ` e: t0 fxi : [ti]0 g ` e: t0 =) `+ n +1 ?1; ?2 ` box e with xi = ei : [t] ?1; ?2 ` box e with xi = ei : [t]n+1 IH `* { Unbox: ?1 ; ?2 ` e: [t]n =) ?1; ?2+1 ` e: [t]n+1 ` + n ?1; ?2 ` unbox e: t ?1; ?2+1 ` unbox e: tn+1 IH `* Lemma 2 Proof: If ? +1 ` e: tn+1 then ? ` e #: t n tu . By structural induction over the rst derivation. { Lambda abstraction: `* ? +1 ; x: t1n+1 ` e: t2n+1 =) ?; x: t1n ` e #: t2n ? +1 ` x:e: t1 ! t2 n+1 ? ` x:e #: t1 ! t2n ` # + IH ; { Variables: ? +1 x = (t; n + 1) =+) ? x = (t; n ) n +1 n+1 =) n  n n ` # + +1 n+1 ? ` x: t ? ` x #: t 0 0 `* 0 0 ; { Applications: ? +1 ` e1 : t1 ! t2n+1 =) ? ` e1 #: t1 ! t2 n ? +1 ` e2 : t1n+1 =) ? ` e2 #: t1n n ` # + +1 n+1 ? ` e 1 e2 : t 2 ? ` e1 e2 #: t2 IH `* IH ; { Run: ? +1 ` ei : [ti]n+1 =) ? ` e #n: [ti ]nn n+1 n+1 +2 ? ; fxi: [ti] g ` e: hti =) ? +1 ; fxi: [ti ] g ` e #n : htin n ` # + +1 n+1 ? ` (run e with xi = ei ) #n: t ? ` run e with xi = ei : t IH `* IH ; { Escape (I): Note that here ~e #= run e. ? +1 ` e: hti0 =) ? +1 ` e: hti0 ` # + `* ? +1 ` ~e: t1 ? ` ~e #: t0 { Escape (II): ? +1 ` e: hti +1 =) ? ` e #: hti ` # + `* ? ` ~e #: t +1 ? +1 ` ~e: t +2 { Bracket: ? +1 ` e: t +2 =) ? ` e #: t +1 `* ? ` hei#: hti ` # + ? +1 ` hei: hti +1 { Box: ? ` e # : [t ] ? +1 ` e : [t ] +1 =) 0 g ` e: t0 fx : [t ]0 g ` e: t0 f x : [ t ] =) `* ? ` (box e with x = e ) # : [t] ? +1 ` box e with x = e : [t] +1 { Unbox: ? ` e # : [t] ? +1 ` e: [t] +1 =) `* +1 ? ` (unbox e) # : t ` # + ? ` unbox e: t +1 ; n n IH n IH n n i i i ; n n n n ; i n IH i i i n i i IH Proof: ?1 ` e1 : tn1 0 and i n n `;# n n n If n i n Lemma 4 i n n ; tu ?1; x: t1n ; ?2 ` e2 : tn2 then ?1; ?2 ` e2 [x: = e1 ]: tn2 . 0 By structural induction over the second derivation. { Lambda abstraction: By Barendregt's convention, y 6= x. 0 ?1 ; x: t1 ; ?2; y: t3 ` e: t4 =) ?1; ?2; y: t3 ` e[x: = e1 ]: t4 `* 0 ?1; ?2 ` y:e[x: = e1 ]: t3 ! t4 ?1; x: t1 ; ?2 ` y:e: t3 ! t4 n n n IH n n n n `;:= n + { Variables (I): If e2 0 = x, we already know ?1 ` e1 : t1 0 . By weakening we have ?1; ?2 ` e1 : t1 , and by n ? n uses of the promotion lemma we have ?1; ?2 ` e1 : t1 . { Variables (II): If e2 = z =6 x, we already know ?1 ; x: t1 0 ; ?2 ` e2: t2 and by weakening we have ?1; ?2 ` e2: t2 . The rest of the cases are completely structural. { Applications: 0 ?1; x: t1 ; ?2 ` e1 : t1 ! t2 =) ?1 ; ?2 ` e1 [x: = e1 ]: t1 ! t2 0 ?1; x: t1 ; ?2 ` e2 : t1 =) ?1 ; ?2 ` e2 [x: = e1 ]: t1 ` + `* 0 ?1; ?2 ` e1 e2 [x: = e1 ]: t2 ? ; x: t ; ? ` e e : t n n 0 n n n n n n n 1 1n n 2 1 2 2n IH IH n n n ;:= + { Run: By applying promotion lemma to the premise ?1 ` e1 : t1 , we get ?1+1 ` n 0 e1 : tn1 +1 . Now, we use these two judgement to apply induction hypothesis. 0 0 ` ` f ` * 0 0 0 { Escape: ` * ` * 0 hi ` `h i hi ?1; ?2 e[x: = e1 ]: t n ?1; ?2 ~e[x: = e1 ]: tn+1 ` ) `h i hi ?1; ?2 e[x: = e1 ]: tn+1 ?1; ?2 e [x: = e1 ]: t n IH { Box: ` ) ) ?1; x: t1n ; ?2 ei : [ti ]n = xi: [ti ]0 e: t0 = n n ?1; x: t1 ; ?2 box e with xi = ei : [t] f * 0 ` 0 g` { Unbox: ` ` ` * 0 0 ` ) ` IH ` `;:= `;:= hi ` f + g` ` 0 `;:= + tu 2 ? ` v: [t]0 ; ` v: [t]0 Since v 2 V 0 and ? ` v: [t]0 , then v = box e for some e. By box rule, the expression e must have type ; ` e: t0. Thus ; ` e: t0 ; ` box e: [t]0 Proposition 1 ? +1 ` e: t e ,! v v2V ? +1 ` v: t By structural induction over the derivation of ,!. +1 { Bottom: ? ,! ? and ? 2 V +1 and ? +1 ` ?: t +1. { Lambda-abstraction I: Interestingly, no induction is needed here. In particular, 0 x:e ,! x:e. By de nition, x:e 2 V 0 , and from the premise ? +1 ` x:e: t0. Lemma 5 If v V0 and then . Proof. If n and n n then n Proof: n n n and + 0 ?1; ?2 e[x: = e1 ]: [t]n ?1 ; ?2 (unbox e)[x: = e1]: tn ` `;:= + ?1; ?2 ei [x: = e1 ]: [ti ]n xi: [ti ]n e: t0 ?1 ; ?2 (box e with xi = ei )[x: = e1 ]: [t]n IH 0 ?1; x: t1n ; ?2 e: [t]n = ?1; x: t1n ; ?2 unbox e: tn 0 g` ) IH ?1 ; x: t1n ; ?2 e: tn+1 = ?1; x: t1n ; ?2 e : t n 0 IH 0 ` hi ` 0 0 ?1; ?2 ei [x: = e1 ]: [ti]n ?1+1 ; ?2+1; xi: [ti ]n e[x: = e1 ]: t n ?1 ; ?2 (run e with xi = ei )[x: = e1 ]: tn IH g` h i ?1; x: t1n ; ?2 e: t n = ?1; x: t1n ; ?2 ~e: tn+1 { Bracket: ` ` f ` ) ) ?1; x: t1n ; ?2 ei : [ti ]n = ?1+1; x: t1n +1 ; ?2+1; xi: [ti ]n e: t n = ?1 ; x: t1n ; ?2 run e with xi = ei : tn n . `;:= + { Lambda-abstraction II: Straight forward induction. ! ! +1 : tn+1 ` e: tn+1 1 ` * ??+1 ;`xx:e : t ! tn+1 ! * 1 { { { ) n+1 e, e = n+1 x:e , x:e , 0 2 e V n+1 x:e V n+1 IH 0 0 0 2 V + ` ? +1; x: tn1 +1 e : tn+1 ` ? +1 x:e : t1 tn+1 ` 0 0 ! Variables I: n = 0 is vacuous, because we can only derive err +1 Variables II: x ,! x and x 2 V +1 and ? +1 ` x: t +1. Applications I: First, we use (twice) the induction hypothesis, which gives us a result that we can use with the substitution lemma (: =): n n n ! ! ` ` ` * ! * , ` ` ` ) ) IH 0 ! 0 ! IH 0 ` ? +1; x: t01 e: t0 ` ? +1 x:e: t1 t0 ? +1 e2 : t01 +1 ? e[x: = e2 ]: t0 0 e1 , x:e ? +1 e1 : t1 t0 = 0 +1 e2 : t01 ? , e e 2 = 2 ` ? +1 e e : t0 0 1 2 e [ x : = e ] , e ! 2 0 e1 e2 , e ! 0 := 0 * + 0 Note that we also use the judgment ? +1; x: t01 ` e: t0 when we apply the substitution lemma. Then, based on this information about e[x: = e2 ] we apply the induction hypothesis for the third time to get e 2 V 0 and ? +1 ` e : t0. { Applications II: 0 `* { 0 +1 e1 ,! e1 =) e1 2 V +1 ` e1: t1 +1! t +1 ` e2: t1 +1 ! * e2 ,!+1 e2 =) e2 2 V +1+1 + +1 e1 e2 2 V ` e 1 e2 : t e1 e2 ,! e1 e2 ? +1 ? +1 ? +1 n n n n n , n 0 IH 0 n 0 IH 0 n 0 0 0 V n 0 ` e1: t1 +1! t +1 ` e2: t1 +1 ` + ` e1 e2: t ? +1 ? +1 ? +1 n 0 n 0 0 0 Run I: First, we apply the induction hypothesis once, then reconstruct the type judgment of the result: ! ) ? +1 ` box e : [t ] 0 ei , box ei ? +1 e1 : [ti ]0 = 0 +2 ; xi: [ti]0 e: t 0 e[xi : = box ei ] , e ? ` +1 ? run e with xi = ei : t0 ! e 0, 0 e 0 run e with xi = ei , e * ` f ` g` h i , * #! 0 0 !h i 0 0 00 ! 0 IH i i 00 By Orthogonality lemmaapplied to ? +1 ` box e : [t ]0, we get ? +2 ` box e : [t ]0 . By Substitution lemmaapplied to ? +2 ` box e : [t ]0 and ? +2; fx : [t ]0 g ` e: hti0 , we get ? +2 ` e[x : = box e ]: hti0 . 0 By IH applied to ? +2 ` e[x : = box e ]: hti0 and e[x : = box e ] ,! he i, we get ? +2 ` he i: hti0. By Bracket rule applied to ? +2 ` he i: hti0 , we get ? +2 ` e : t1. By Demotion lemma applied to ? +2 ` e : t1, we get ? +1 ` e : t0. 0 i i 0 0 i i 0 i i i i i 0 i 0 i i 0 0 i 0 0 0 0 i 0 n + { Run II: For space reason, we assume R = run e with x = e1 . 0 `* { i ` f ? +1 ei : [ti ]n+1 ? +2; xi: [ti ]n+1 e: t n+1 ! ? +1 R: tn+1 0 ` g` h i , ! * ! ! n+1 ei , e i = n+1 e, e = R n,+1 R ) e 2 V +1+1 ) e 2 V +1 + R 2V IH 0 0 * ` hi ` 2 V 10 * * !!h i ) h i 2 V e e n V n ` f ? +1 ei : [ti]n+1 ? +2; xi: [ti ]n+1 e : t n+1 ` ? +1 R : tn+1 0 ` , ` `h i hi * ? +1 e : t1 ` +1 ? e : t0 0 0 IH 0 V 0 0 00 Escape II: IH 0 , 0 0 0 Bracket: n+1 +1 n+1 e ` * ??+1 ``hee:it: htin ! * e ,! n 0 hei ,! he i , { n 0 0 n+1 +1 n+1 e =) e 2 V n+1 ` * ?? +1 `` e~:eh:ttin+2 ! * e n,! +2 ~e 2 V n+2 ~e ,! ~e { 0 i IH 0 Escape I: 0 +1 e: t 0 e , e = ? ` ? +1 ~e: t1 ! 1 ~e , e { e with xi = e1 and R = run 0 0 + 2 V +1 + he i 2 V =) e IH V n 0 n V 0 ` hi ` ? +1 e : t n+1 ? +1 ~e : tn+2 ` 0 0 + ` `h i hi + ? +1 e : tn+1 ` ? +1 e : t n 0 0 Box I: First, we apply the induction hypothesis once, then reconstruct the type judgment of the result: ` f * ` g` ! * ! ` ? +1 box ei : [ti ]0 ) 0 ? +1 e1 : [ti]0 ei , box ei = 0 e: t0 x i : [ti ] ! ` +1 ? B: [t]0 B , 0 box e[xi: = box ei ] , IH 0 0 0 By Orthogonality lemma applied to ? +1 ` box e : [t ]0, we get fg ` box e : [t ]0 . By Substitution lemma applied to fg ` box e : [t ]0 and fx : [t ]0g ` e: t0, we get fg ` e[x : = box e ]: t0. By Box rule applied to fg ` e[x : = box e ]: t0, we get ? +1 ` box e[x : = box e ]: t0. { Box II: For space reason, we assume B = box e with x = e1 and B = box e with x = e1 . 0 i 0 i i 0 i i 0 i i i i i 0 i i i 0 i 0 i i ` f g` `* ` 0 ? +1 ei : [ti ]n+1 xi: [ti ]0 e: t0 ! ? +1 B: [t]n+1 , !+1 e =) e 2 V * B ,!+1 B =) B 2 V n ei , n 0 i 0 IH +1 0 n 0 n i +1 ` + f ` g` ? +1 ei : [ti]n+1 xi: [ti ]0 e : t0 ` ? +1 B : tn+1 0 V 0 0 + g` h i 0 0 + { Unbox I: fg ` e0 : t0 0 0 0 `* IH box e 2 V +1 e ,! box e0 ? ` box e0 : [t]0 =) 1 e0 ,! e00 ,! * ` * +1 0 0 ? ` unbox e: t unbox e ,! e00 ? +1 ` e: [t]0 By Weakening lemma applied to fg ` e0 : t0, we get ? + ` e0 : t0. By IH applied 1 00 to ? +1 ` e0 : t0 and e0 ,! e , we get ? +1 ` e00 : t0. { Unbox II: n+1 +1 ` e: [t]n+1 e ,! e0 ? =IH) e0 2 V n+1 V + ? +1 ` e0 : [t]n+1 ,! * ` * +1 n +1 n +2 unbox e0 2 V n+1 ? ` unbox e: t ? +1 ` unbox e0 : tn+1 unbox e ,! unbox e0 t u Lemma 4 The judgment ? n `o (? )+r ` e: tn is also derivable. e: t; r is derivable if and only if the judgment Remark 2 (Environment Restriction). Technically, we also assume ? x = (t; n0; r0) imply r0  r. The restriction \? x = (t; n0 ; r0) implies r0  r" is implicit in the original type system. In particular, r never decreases when we go from the conclusion of a type rule to it's premise, thus, we never add a binding with an r higher than that of the judgement. Proof: By structural induction over the rst and the second derivations (to prove the implications in both directions). The di erent cases for each of the two derivations are one-to-one, and so we combine corresponding pairs and do the proof in both directions for each pair. { Lambda abstraction: n IH; ?; x: (t1; n; r) `o e: t2 ; r () (? )+r ; x: t1n?r+r ` e: t2 n ;` m `o m n (? )+r ` x:e: t1 ! t2 n ? `o x:e: t1 ! t2 ; r { Variables:  ? x = (t; n0; r0) () (? )+r x = (t; n0 ? r0 + r) 0 0  n + r  n + r () n0 ? r0 + r  n n `m `o m (? )+r ` x: tn ? `o x: t; r { Applications: n IH ? `o e1 : t1 ! t2 ; r () (? )+r ` e1 : t1 ! t2n n +r n IH () (? ) ` e2 : t1 `o m ? `one2 : t1; r + r (? ) ` e1 e2 : t2n ` m ? `o e1 e2 : t2; r `+ { Run: { Escape: { Bracket: n IH (? )+r+1 ` e: htin ? `o e: hti; r + 1 () `o m n (? )+r ` run e: tn ` m ? `o run e: t; r n IH ? `o e: hti; r () (? )+r ` e: htin ` m `o m n+1 (? )+r ` ~e: tn+1 ? `o ~e: t; r `o m n+1 IH (? )+r ` e: tn+1 ? `o e: t; r () n (? )+r ` hei: htin ` m ? `o hei: hti; r B Proofs of the Embedding of  B.1 Strong Normalisation The proof follows Harper, Honsell, and Plotkin [7]. We present a translation into the simply-typed -calculus. This translation essentially ignores all details of the original expression, except for the cases when there is a Box-redex, in which case the translation produces a term with a -redex. We translate raw terms of the closed fragment into terms of the simply typed -calculus with one base type o and additional constants app : o ! (o ! o) abs : (o ! o) ! o The mapping for types is simply: t = o. The mapping for terms is x = x (e1 e2 ) = app e1 e2 (x:e) = abs (x: o:e ) (unbox e) = (x: o:x) e (box e) = e (box e with xi = ei ) = (x1 : o: : : : (xn : o:e ) en : : : ) e1 Next, we show that e1 !box e2 implies e1 !beta e2 . First, we make sure that the terms produced by the translation are indeed in the simply typed -calculus, in particular, that they are well-typed. Lemma 9 (Star Well-Typedness). fxi: og ` e : o. Proof. If e 2 EClosed By induction over the typing derivation. and FV(e)  fxig, then t u Then, we prove the following distributivity property that will be needed to prove strong normalization. Lemma 10 (Star Substitution). e[x: = e0  ]  (e[x: = e0 ]) . Proof. By induction on the structure of e. One issue arising in this proof is the need for substitution to propagate into the body of Box expressions, which is not needed when we are dealing only with well-typed terms. tu Lemma 11 (Lockstep). If e1 !box e2 then e1 ! e2. Proof. By induction on the derivation of !box. Most cases are treated by an application of the induction hypothesis, with the exception of the two cases when a Box reduction takes place explicitly. The interesting case is when e1  box e0 with xi = ei ; x = box e; xj = ej and then e2  box e0 [x: = box e] with xi = ei ; xj = ej we proceed as follows: = ! = e1 (xjn : o: : : : (x: o: : : : (xi1 : o:e0 ) ei1 : : : ) (box e) : : : ) ejn (xjn : o: : : : : : : (xi1 : o:e0 [x: = (box e) ]) ei1 [x: = (box e) ] : : : : : : ) ejn By Barendregt's convention for variable names x 62 FV(ei ) (xjn : o: : : : : : : (xi1 : o:e0 [x: = (box e) ]) ei1 : : : : : : ) ejn By Star Distribution lemma = (xjn : o: : : : : : : (xi1 : o:(e0[x: = box e]) ) ei1 : : : : : : ) ejn = box e0 [x: = box e] with xi = ei ; xj = ej tu Finally, we can prove our main lemma Lemma 12 (Strong Normalization). !box is strongly normalizing. Proof. From Lockstep, and because the simply-typed -calculus is strongly nor- malizing, it follows that Box-reduction is likewise. tu B.2 Con uence Lemma 13. The !box relation is sub-commutative. Proof. The only critical pair is the second rule with it self. It easy to check it is convergent and close in one step. Corollary 1. The !box relation is con uent. Proof. Direct consequence of the previous lemma. B.3 Compatibility w.r.t the semantics of AIM box fragment We use the notion of parallel reduction to deal with duplication of redices caused by substitution. Roughly speaking, parallel reduction is de ned by the simultaneous reduction of a set of redices in a term. De nition 7 (Parallel Reduction). q!box is formally de ned as follows: ! unbox box ! ! ! ! = box ! box [ : = box e e = box a with xi a q box a 0 b ci ; x 0 q box e q box 0 q box b ci 0 q box c0i 0 q box b e a x b 0 ] with xi = 0 ci and the usual distribution rules for all constructs including the unbox and box constructs. Constants and variables are axioms. Lemma 14 (Parallel Reduction and Substitution). If ! 0 box b then a[x: = b] q!box a [x: = b ]. 0 a 0 ! q box a 0 and b q Proof. Induction on the structure of a. Lemma 15 (Soundness of !box). If v1 0 v1 and v1 q !box v2. such that e1 ,! e1 ! q box e2 0 v2 then there exists and e2 ,! 0 v2 Proof. Induction on the lexicographic composition of the derivation of e2 ,! and the derivation of 1 q!box 2 . If one of the redices of 1 is at the root then two cases are possible: e e e 1. If 1 = unbox box then 0 By applying IH to 2 ! Thus, we have e e e , ! q box e1 and v2 and e q box e e e ! !0 box box e , ! . 2 , we derive q box e e a a 0 a b = ! xi ! q box b b v 0 !0 ci , and v1 ! q box v2 . v1 v1 0 vi 0 e c box a0[x: = box b0] with xi 0 v1 a x b 0 x c 0 0 c 0 By applying the IH to i . Thus 0 !0 e , = box then 2 = box [ : = box ] with i = i , ,and i q!box i . By the semantics of box , we know ci ; x 0 !0 e , unbox box e , 2. If 1 = box with where q!box , that: e2 = and !0 !0 box [ : = box ][ : = ] ! , we derive !0 and ! ci , 0 vi 0 ci , ci q box c0i a 0 x b 0 ci , xi vi 0 vi vi q box ci ,! vi box b ,! box b 0 0 0 box a[x: = box b][xi: = vi ] = ci ; x = box b ,! and by lemma 14, we drive box a[x: = box b][xi: = vi ] q!box box a [x: = box b ][xi: = vi ] since a q!box a , b q!box b , and vi q!box vi . box a with xi 0 0 0 0 0 0 If all redices are subterms of e1 . If e1 = x:e and e2 = x:e such that e q!box e . It is easy the check that v1 = x:e and v2 = x:e . hence, v1 q!box v2. { If e1 = a b and e2 = a b such that a q!box a and b q!box b . we know that { 0 0 0 0 0 0 0 a0 ,! x:e0 b0 ,! v0 e0 [x: = v0 ] ,! v2 0 0 0 a0 b0 ,! v2 0 0 0 By applying IH to a ,! x:e and a q!box a and then to b ,! v and b q!box b , 0 0 we derive a ,! x:e and x:e q!box x:e , and b ,! v and v q!box v . By lemma 14, e[x: = v] q!box e [x: = v ]. Thus, we can apply the induc0 tion hypothesis to e [x: = v ] ,! v2 and e[x: = v] q!box e [x: = v ] to derive 0  e[x: = v] ,! v1 and v1 ?!box v2 . Hence, 0 0 0 0 0 0 0 0 0 0 0 0 0 0 a ,! x:e b ,! v e[x: = v0 ] ,! v1 0 0 0 a b ,! v1 0 { If e1 = box a with xi = bi and e2 = box a and bi q!box bi . We know that; 0 0 with xi = bi such that a q!box a 0 0 b0i ,! vi0 0 e2 ,! box a0[xi: = vi0 ] 0 0 Notice that v2 = box a [xi: = vi ]. By applying IH to bi ,! vi and bi q!box bi , we 0 derive bi ,! vi and vi q!box vi . By Lemma 14, we have a[xi: = vi ] q!box a [xi: = vi ] since a q!box a and vi q!box vi . Thus, box a[xi: = vi ] q!box box a [xi: = vi ] and 0 0 0 0 0 0 0 0 0 0 0 bi ,! vi 0 0 box a[xi: = vi ] = bi ,! { e1 = unbox e and e2 = unbox e such that e q!box e . we have box a with xi 0 0 e0 ,! box a0 a0 ,! v2 0 0 unbox e0 ,! v2 0 0 0 0 by applying IH to e ,! box a and e q!box e , we derive e ,! box a and box a q 0 !box box a . Hence, a q!box a . Thus IH applies to a ,! v2 and a q!box a , to 0 derive a ,! v1 and v1 q!box v2 . We conclude by 0 0 0 0 0 0 0 e ,! box a a ,! v2 0 0 unbox e ,! v2 0 Corollary 2. If e1 !box e2 and e2 ,!0 v2 then there exists v1 such that e1 ,!0 v1  and v1 ?!box v2. Proof. Use the precedent lemma, and the facts that !boxq!box for the hypoth esis and q!box  ?! for the conclusion of this corollary. B.4 Substitutivity Lemma 16 (Weakening). If FV(e) \ S = ; then eT = eT S . [ Proof. By induction on the structure of e. Box case requires some simple set tu logic. Lemma 8 Given a closed term e0 2 E the following properties hold: { eX [y: = e0 ]  (e[y: = e 0 ])X , provided y 62 X { eX x [x: = box e0 ] ?!box (e[x: = e0 ])X ; ; [f g Proof. By induction over the structure of e, for both properties. The interesting case|in both proofs|is Box, which requires explicit reasoning about sets of free variables. Some Variable sub-cases require Weakening (Lemma 16). tu B.5 Main Result: Embedding of  Proposition 6 If e 2 E is closed and e ,! v is derivable in  , then there 0   exists v such that e ,! v and v ?! box v . Proof. Induction on the derivation of e ,! v. { If e = x, vacuous { If e = box e1 then we have: box e1 ,! box e1 and box e = box e , hence 0 box e ,! box e { If e = e1 e2, we have e1 ,! x:e (1) e2 ,! v (2) e [x: = v ] ,! v (3) e1 e2 ,! v 0 ; 0 0 ; ; ; ; 0 0 0 0 ; 0 By applying respectively (IH) to (1), (2) and (3), we derive e1 ,! x:e , 0 0    e2 ,! v , and e [x: = v ] ,! v1 such that x:e ?!box (x:e ) , v ?!box    (v ) , and v1 ?!box v .   By lemma 8, we have e [x: = v ] = (e ) [x: = (e ) ]. Since e ?! box (e )    and v ?!box (v ) , we have e [x: = v ] ?!box (e ) [x: = (e ) ]. 0 Hence, we apply the compatibility lemma to derive: e [x: = v ] ,! v1 and  ; ; 0 00 0 0 ; ; 00 0 ; 00 00 ; 0 00 0 0 ; v1 ?!box v1  ; Thus, v10 ?! box v ; 0 00 ; 0 00 ; 0 00 ; 0 0 00 ; ; 00 0 0 and ; ; 00 00 e e e00 [x: = e00 ] ,! v10 1 ,! x:e 2 ,! v 0 0 0 0 (e1 e2 ) ,! v1 ; { 0 If e = let box x = e1 in e2 , we have e1 ,! box e3 (1) e2 [x: = e3 ] ,! v0 (2) let box x = e1 in e2 ,! v 0 0 By applying respectively (IH to (1) and (2), we derive: e1 ,! v1 and e2 [x: = e3 ] ,!    v such that v1 ?!box box e3 and v ?!box v . Since v1 2 V 0 rewrite to box e3 then v1  box e4 . By hypothesis and typing rule we know fx:  t g; ; ` e2 : t. Hence, we can apply property 2 of Lemma 8, we have: ; ; 0 ; ; ; 0 fxg e [x: = box e4 ] ?!box e2 fxg [x: = box e3 ; ] ?!box e2 [x: = e3 ]; 2   0  By compatibilityof !box, we have: e2 x [x: = box e1 ] ,! v and v ?! box v .  thus, v ?!box v and f g ; 00 ; e 1 ,! box e4 0  e2 fxg [x: = box e4 ] ,! v00 0 ; 00 let box x = e1 in e 2 ,! v 0 00 00 0