INTEROPERATION FOR LAZY AND EAGER EVALUATION. A Thesis. Presented to. the Faculty of California Polytechnic State University.

Transcription

1 INTEROPERATION FOR LAZY AND EAGER EVALUATION A Thesis Presented to the Faculty of California Polytechnic State University San Luis Obispo In Partial Fulfillment of the Requirements for the Degree Master of Science in Computer Science by William Faught May 2011

2 2011 William Faught ALL RIGHTS RESERVED ii

3 COMMITTEE MEMBERSHIP TITLE: Interoperation for Lazy and Eager Evaluation AUTHOR: William Faught DATE SUBMITTED: May 2011 COMMITTEE CHAIR: COMMITTEE MEMBER: COMMITTEE MEMBER: John Clements, Dr. Gene Fisher, Dr. Phillip Nico, Dr. iii

4 Abstract Interoperation for Lazy and Eager Evaluation by William Faught Programmers forgo existing solutions to problems in other programming languages where software interoperation proves too cumbersome; they remake solutions, rather than reuse them. To facilitate reuse, interoperation must resolve language incompatibilities transparently. To address part of this problem, we present a model of computation that resolves incompatible lazy and eager evaluation strategies using dual notions of evaluation contexts and values to mirror the lazy evaluation strategy in the eager one. This method could be extended to resolve incompatible evaluation strategies for any pair of languages with common expressions. iv

5 Acknowledgements I am grateful for the support of my parents, Jerry and Jo Ann, and my uncle, Tim. I could not have done this without them. v

6 Contents List of Figures vii 1 Introduction 1 2 Model of Computation 5 3 Proof of Type Soundness 28 4 Conclusion 31 Bibliography 32 vi

7 List of Figures 1.1 Transparency broken for list construction operands Transparency not broken for list construction operands Transparency broken for function arguments Transparency not broken for function arguments Symbol names Syntax names Syntax names The unbrand function The lump equality relation The Haskell syntax and evaluation contexts The Haskell typing rules The Haskell operational semantics The Haskell-ML operational semantics The Haskell-Scheme operational semantics The ML syntax and evaluation contexts The ML typing rules The ML operational semantics The ML-Haskell operational semantics The ML-Scheme operational semantics The Scheme syntax and evaluation contexts The Scheme typing rules The Scheme operational semantics vii

8 2.19 The Scheme-Haskell operational semantics The Scheme-ML operational semantics viii

9 Chapter 1 Introduction Programmers forgo existing solutions to problems in other programming languages where software interoperation proves too cumbersome; they remake solutions, rather than reuse them. To facilitate reuse, interoperation must resolve language incompatibilities transparently. To address part of this problem, we present a model of computation that resolves incompatible lazy and eager evaluation strategies. Matthews and Findler presented a method of type-safe interoperation between languages with incompatible polymorphic static and dynamic type systems [3]. We observe that their method is insufficient for transparent interoperation between languages with incompatible lazy and eager evaluation strategies. We explain the underlying problem and present a method of interoperation that resolves this incompatibility. The model of computation of Matthews and Findler comprises two eager languages based on ML and Scheme. We extend their model of computation with a third language that is based on Haskell and identical to their ML-like 1

10 language, except it is lazy. We introduce lists to all three languages. Types are equal up to alpha equivalence. Letter subscripts denote languages. Languages do not share variables or type variables. Hereafter, we use the names of Haskell, ML, and Scheme to refer to their counterparts in our model of computation. Unlike ML and Scheme, Haskell does not evaluate function arguments or list construction operands. These three evaluation contexts comprise the set of incompatible evaluation contexts between Haskell and ML, and Haskell and Scheme. Since Haskell permits unused erroneous or divergent expressions in these evaluation contexts and ML and Scheme do not, there are Haskell values that have no counterpart in ML and Scheme. Attempting to convert such values to ML and Scheme forces the evaluation of such expressions and breaks the transparency of interoperation. Figure 1.1 demonstrates how a straightforward introduction of Haskell to the model of Matthews and Findler breaks the transparency of interoperation when converting a list construction from Haskell to Scheme. The Haskell list construction contains an erroneous operand that Scheme forces to evaluate in the process of converting the Haskell list construction. Figure 1.2 demonstrates Scheme correctly deferring the evaluation of the erroneous Haskell list construction operand and producing as a result the counterpart Scheme list construction. Moreover, since the conversion of functions from ML and Scheme to Haskell requires the application of the original function to the converted Haskell argument, ML and Scheme always force the evaluation of the converted Haskell argument, even if it is never used. The application of such converted functions effectively changes the order of evaluation of Haskell and breaks the transparency of interoperation. 2

11 Likewise, figure 1.3 demonstrates the conversion of a function from Haskell to Scheme. Scheme forces the evaluation of the erroneous Haskell argument in the process of applying the Scheme function, even though the Haskell argument is never used. From the perspective of the outermost Haskell application, the argument must have been used, but it was not. Figure 1.4 demonstrates Scheme not forcing the evaluation of the Haskell argument, which allows the Scheme function to produce a number. 3

12 Figure 1.1: Transparency broken for list construction operands. sh {N} (cons (wrong N Not a number ) (nil N)) cons (sh N (wrong N Not a number )) (sh {N} (nil N)) Error: Not a number Figure 1.2: Transparency not broken for list construction operands. sh {N} (cons (wrong N Not a number ) (nil N)) cons (sh N (wrong N Not a number )) (sh {N} (nil N)) cons (sh N (wrong N Not a number )) (nil N) Figure 1.3: Transparency broken for function arguments. (hs (N N) (λx S.0)) (wrong N Not a number ) (λx H : N.hs N ((λx S.0) (sh N x H ))) (wrong N Not a number ) hs N ((λx S.0) (sh N (wrong N Not a number ))) Error: Not a number Figure 1.4: Transparency not broken for function arguments. (hs (N N) (λx S.0)) (wrong N Not a number ) (λx H : N.hs N ((λx S.0) (sh N x H ))) (wrong N Not a number ) hs N ((λx S.0) (sh N (wrong N Not a number ))) hs N 0 0 4

13 Chapter 2 Model of Computation To preserve the transparency of interoperation, ML and Scheme must not force Haskell to evaluate reducible expressions in Haskell boundaries in the incompatible evaluation contexts, and must force their evaluation in all other evaluation contexts. Haskell boundaries must be a new kind of value that ML and Scheme can force to become a reducible expression in certain evaluation contexts, and thereby force the evaluation of the inner Haskell reducible expressions to Haskell values and the conversion of those values to ML or Scheme. Since ML and Scheme do not force Haskell to evaluate in some evaluation contexts, we must factor Haskell boundaries out of ML and Scheme evaluation context nonterminals, E, into new evaluation context nonterminals. We name these new nonterminals F because they allow ML and Scheme to force Haskell to evaluate, and we rename the primary evaluation context nonterminals from E to U (unforced) because they do not. Likewise, we factor Haskell boundaries out of ML and Scheme value nonterminals, v, into new value nonterminals. We name these new nonterminals f (forced) and rename the old value nonterminals from v to u (unforced). We rename Haskell evaluation contexts and values to F and 5

14 f, respectively. In ML and Scheme, we tie F and U together by replacing U with F in the syntax and operational semantics in all evaluation contexts except the incompatible ones. Likewise, we tie f and u together by replacing u with f in the syntax and operational semantics in those same evaluation contexts. F evaluation contexts produce f values, and U evaluation contexts produce u values. U only applies to incompatible evaluation contexts, and F applies to all others. ML and Scheme use F to evaluate expressions. We rename the meta evaluation context from E to F. Transparency is restored for interoperation in all cases with our changes to the model of computation of Matthews and Findler. Theorem 1. Interoperation is transparent: 1. e H hm t H t M (mh t M t H e H ) hs k H (sh k H e H ) 2. e M mh t M t H (hm t H t M e M ) ms k M (sm k M e M ) 3. e S sh k H (hs k H e S ) sm k M (ms k M e S ) where denotes observational equivalence [1]. Proof. By structural induction. The conversion of type abstractions between Haskell and ML was not straightforward. The application of a converted type abstraction cannot substitute the type argument into the nested expression because the type argument is meaningless in the nested expression s language. Instead, the application substitutes the type argument and a lump into the boundary s outer and inner types, respectively. Since the natural embedding requires the boundary s outer and inner 6

15 types to be equal [3], we use a new notion of equality called lump equality that allows lumps within the boundary s inner type to match any corresponding type in the boundary s outer type. Figures present legends of symbol and syntax names; figure 2.4 presents the unbrand function; figure 2.5 presents the lump equality relation; figures present Haskell; figures present ML; and figures present Scheme. 7

16 b k e F f Figure 2.1: Symbol names Brand Conversion scheme Expression Forced evaluation context Forced value L Lump. = Lump equality relation F n N t y Γ U u x Meta evaluation context Natural number Natural number Reduction relation Type Type variable Typing environment Typing relation Unforced evaluation context Unforced value Variable 8

17 Figure 2.2: Syntax names + e e Addition if0 e e e Condition nil t Empty list nil Empty list null? e Empty list predicate wrong t string Error wrong string Error λx : t.e Function abstraction λx S.e S Function abstraction fun? e S Function abstraction predicate e e Function application hm t H t M e M Haskell-ML guard hs k H e S Haskell-Scheme guard cons e e List construction hd e List head list? e S List predicate tl e List tail mh t M t H e H ML-Haskell guard ms k M e S ML-Scheme guard num? e S Number predicate sh k H e H Scheme-Haskell guard sm k M e M Scheme-ML guard e e Subtraction Λy.e Type abstraction e t Type application 9

18 Figure 2.3: Syntax names b t y.t y.k t t k k {t} {k} Branded type Forall type Forall conversion scheme Function abstraction Function abstraction List List 10

19 Figure 2.4: The unbrand function. L = L N = N y H = y H y M = y M {k H } = { k H } {k M } = { k M } k H k H = k H k H k M k M = k M k M y H.k H = y H. k H y M.k M = y M. k M b t H = t H b t M = t M 11

20 Figure 2.5: The lump equality relation. x =. x x =. y y =. x x =. y and y =. z x =. z. t H = L. = L t M t H = t M t H. = tm 12

21 Figure 2.6: The Haskell syntax and evaluation contexts. e H = x H f H e H e H e H t H a e H e H if0 e H e H e H c e H null? e H wrong t H string hm t H t M e M hs k H e S f H = λx H : t H.e H Λy H.e H n nil t H cons e H e H hm L t M f M hs L f S t H = L N y H {t H } t H t H y H.t H k H = L N y H {k H } k H k H y H.k H b t H a = + c = hd tl F H = [ ] H F H e H F H t H a F H e H a f H F H if0 F H e H e H c F H null? F H hm t H t M F M hs k H F S 13

22 Figure 2.7: The Haskell typing rules. H L H N Γ, y H H y H Γ H t H Γ H {t H } Γ H t H Γ H t H Γ H t H t H Γ, y H H t H Γ H y H.t H Γ H t H Γ, x H : t H H e H : t H Γ H (λx H : t H.e H ) : t H t H Γ H t H Γ H nil t H : {t H } Γ, y H H e H : t H Γ H Λy H.e H : y H.t H Γ H e H : t H Γ H e H : {t H } Γ H cons e H e H : {t H } H n : N Γ, x H : t H H x H : t H Γ H e H : N Γ H e H : t H t H Γ H e H : t H Γ H t H Γ H e H : y H.t H Γ H e H e H : t H Γ H e H t H : t H [t H /y H ] Γ H e H : N Γ H e H : N Γ H e H : t H Γ H e H : t H Γ H a e H e H : N Γ H if0 e H e H e H : t H Γ H e H : {t H } Γ H null? e H : N Γ H e H : {t H } Γ H e H : {t H } Γ H hd e H : t H Γ H tl e H : {t H } Γ H t H Γ H k H Γ S e S : TST Γ H wrong t H string : t H Γ H hs k H e S : k H Γ H t H Γ M t M Γ M e M : t M t. H = t M t M = t M Γ H hm t H t M e M : t H 14

23 Figure 2.8: The Haskell operational semantics. F [(λx H : t H.e H ) e H ] H F [e H [e H /x H ]] F [(Λy H.e H ) t H ] H F [e H [b t H /y H ]] F [+ n n ] H F [n + n ] F [ n n ] H F [max(n n, 0)] F [if0 0 e H e H ] H F [e H ] F [if0 n e H e H ] H F [e H ] (n 0) F [hd (nil t H )] H F [wrong t H Empty list ] F [tl (nil t H )] H F [wrong {t H } Empty list ] F [hd (cons e H e H )] H F [e H ] F [tl (cons e H e H )] H F [e H ] F [null? (nil t H )] H F [0] F [null? (cons e H e H )] H F [1] F [wrong t H string] H Error: string 15

24 Figure 2.9: The Haskell-ML operational semantics. F [hm t H t M (mh t M t H e H )] H F [e H ] (t H L t H = t H ) F [hm t H t M (mh t M t H e H )] H F [wrong t H Type mismatch ] (t H L t H t H ) F [hm t H L (ms L f S )] H F [wrong t H Bad value ] (t H L) F [hm N N n] H F [n] F [hm {t H } {t M } (nil t M )] H F [nil t H ] F [hm {t H } {t M } (cons u M u M )] H F [cons (hm t H t M u M ) (hm {t H } {t M } u M )] F [hm (t H t H ) (t M t M ) (λx M : t M.e M )] H F [λx H : t H.hm t H t M ((λx M : t M.e M ) (mh t M t H x H ))] F [hm ( y H.t H ) ( y M.t M ) (Λy M.e M )] H F [Λy H.hm t H t M [L/y M ] e M [L/y M ]] 16

25 Figure 2.10: The Haskell-Scheme operational semantics. F [hs t H (sh t H e H )] H F [e H ] (t H = t H ) F [hs N n] H F [n] F [hs N f S ] H F [wrong N Not a number ] (f S n) F [hs {k H } nil] H F [nil k H ] F [hs {k H } (cons u S u S )] H F [cons (hs k H u S ) (hs {k H } u S )] F [hs {k H } f S ] H F [wrong {k H } Not a list ] (f S nil and f S cons u S u S ) F [hs (b t H ) (sh (b t H ) e H )] H F [e H ] F [hs (b t H ) f S ] H F [wrong t H Brand mismatch ] (f S sh (b t H ) e H ) F [hs (k H k H ) (λx S.e S )] H F [λx H : k H.hs k H ((λx S.e S ) (sh k H x H ))] F [hs (k H k H ) f S] H F [wrong k H k H Not a function ] (f S λx S.e S ) F [hs ( y H.k H ) f S ] H F [Λy H.hs k H f S ] 17

26 Figure 2.11: The ML syntax and evaluation contexts. e M = x M u M e M e M e M t M a e M e M if0 e M e M e M cons e M e M c e M null? e M wrong t M string ms k M e S u M = f M mh t M t H e H f M = λx M : t M.e M Λy M.e M n nil t M cons u M u M mh L t H e H ms L f S t M = L N y M {t M } t M t M y M.t M k M = L N y M {k M } k M k M y M.k M b t M a = + c = hd tl F M = U M mh t M t H F H U M = [ ] M F M e M f M U M F M t M a F M e M a f M F M if0 F M e M e M cons U M e M cons u M U M c F M null? F M ms k M F S 18

27 Figure 2.12: The ML typing rules. M L M N Γ, y M M y M Γ M t M Γ M {t M } Γ M t M Γ M t M Γ M t M t M Γ, y M M t M Γ M y M.t M Γ M t M Γ, x M : t M M e M : t M Γ M (λx M : t M.e M ) : t M t M Γ M t M Γ M nil t M : {t M } Γ, y M M e M : t M Γ M Λy M.e M : y M.t M Γ M e M : t M Γ M e M : {t M } Γ M cons e M e M : {t M } M n : N Γ, x M : t M M x M : t M Γ M e M : t M t M Γ M e M : t M Γ M t M Γ M e M : y M.t M Γ H e M e M : t M Γ M e M t M : t M [t M /y M ] Γ M e M : N Γ M e M : N Γ M e M : N Γ M e M : t M Γ M e M : t M Γ M a e M e M : N Γ M if0 e M e M e M : t M Γ M e M : {t M } Γ M null? e M : N Γ M e M : {t M } Γ M e M : {t M } Γ M hd e M : t M Γ M tl e M : {t M } Γ M t M Γ M k M Γ S e S : TST Γ M wrong t M string : t M Γ M ms k M e S : k M Γ M t M Γ H t H Γ H e H : t H t M. = th t H = t H Γ M mh t M t H e H : t M 19

28 Figure 2.13: The ML operational semantics. F [(λx M : t M.e M ) u M ] M F [e M [u M /x M ]] F [(Λy M.e M ) t M ] M F [e M [b t M /y M ]] F [+ n n ] M F [n + n ] F [ n n ] M F [max(n n, 0)] F [if0 0 e M e M ] M F [e M ] F [if0 n e M e M ] M F [e M ] (n 0) F [hd (nil t M )] M F [wrong t M Empty list ] F [tl (nil t M )] M F [wrong {t M } Empty list ] F [hd (cons u M u M )] M F [u M ] F [tl (cons u M u M )] M F [u M ] F [null? (nil t M )] M F [0] F [null? (cons u M u M )] M F [1] F [wrong t M string] H Error: string 20

29 Figure 2.14: The ML-Haskell operational semantics. F [mh t M t H (hm t H t M f M )] M F [f M ] (t M L t M = t M ) F [mh t M t H (hm t H t M f M )] M F [wrong t M Type mismatch ] (t M L t M t M ) F [mh t M L (hs L f S )] H F [wrong t M Bad value ] (t M L) F [mh N N n] M F [n] F [mh {t M } {t H } (nil t H )] M F [nil t M ] F [mh {t M } {t H } (cons e H e H )] M F [cons (mh t M t H e H ) (mh {t M } {t H } e H )] F [mh (t M t M ) (t H t H ) (λx H : t H.e H )] M F [λx M : t M.mh t M t H ((λx H : t H.e H ) (hm t H t M x M ))] F [mh ( y M.t M ) ( y H.t H ) (Λy H.e H )] M F [Λy M.mh t M t H [L/y H ] e H [L/y H ]] 21

30 Figure 2.15: The ML-Scheme operational semantics. F [ms N n] M F [n] F [ms N f S ] M F [wrong N Not a number ] (f S n) F [ms {k M } nil] M F [nil k M ] F [ms {k M } (cons u S u S )] M F [cons (ms k M u S ) (ms {k M } u S )] F [ms {k M } f S ] M F [wrong {k M } Not a list ] (f S nil and f S cons u S u S ) F [ms (b t M ) (sm (b t M ) u M )] M F [u M ] F [ms (b t M ) f S ] M F [wrong b t M Brand mismatch ] (f S sm (b t M ) e M ) F [ms (k M k M ) (λx S.e S )] M F [λx M : k M.ms k M ((λx S.e S ) (sm k M x M ))] F [ms (k M k M ) f S] M F [wrong k M k M Not a function ] (f S λx S.e S ) F [ms ( y M.k M ) f S ] M F [Λy M.ms k M f S ] 22

31 Figure 2.16: The Scheme syntax and evaluation contexts. e S = x S u S e S e S a e S e S p e S if0 e S e S e S cons e S e S c e S wrong string sm k M e M u S = f S sh k H e H f S = λx S.e S n nil cons u S u S sh (b t H ) e H sm (b t M ) f M a = + c = hd tl p = fun? list? null? num? F S = U S sh k H F H U S = [ ] S F S e S f S U S a F S e S a f S F S p F S if0 F S e S e S cons U S e S cons u S U S c F S sm k M F M 23

32 Figure 2.17: The Scheme typing rules. S TST Γ, x S : TST S e S : TST Γ S λx S.e S : TST S n : TST S nil : TST Γ S e S : TST Γ S e S : TST Γ S cons e S e S : TST Γ, x S : TST S x S : TST Γ S e S : TST Γ S e S : TST Γ S e S : TST Γ S e S : TST Γ H e S e S : TST Γ S a e S e S : TST Γ S e S : TST Γ S e S : TST Γ S e S : TST Γ S if0 e S e S e S : TST Γ S e S : TST Γ S c e S : TST S wrong string : TST Γ H k H Γ H e H : t H k H = t H Γ S sh k H e H : TST Γ M k M Γ M e M : t M k M = t M Γ S sm k M e M : TST Γ S e S : TST Γ S p e S : TST 24

33 Figure 2.18: The Scheme operational semantics. F [(λx S.e S ) u S ] S F [e S [u S /x S ]] F [f S u S ] S F [wrong Not a function ] (f S λx S.e S ) F [+ n n ] S F [n + n ] F [ n n ] S F [max(n n, 0)] F [a f S f S ] S F [wrong Not a number ] (f S n or f S n) F [if0 0 e S e S ] S F [e S ] F [if0 n e S e S ] S F [e S ] (n 0) F [if0 f S e S e S ] S F [wrong Not a number ] (f S n) F [c nil] S F [wrong Empty list ] F [hd (cons u S u S )] S F [u S ] F [tl (cons u S u S )] S F [u S ] F [c f S ] S F [wrong Not a list ] (f S nil and f S cons u S u S ) F [fun? (λx S.e S )] S F [0] F [fun? f S ] S F [1] (f S λx S.e S ) F [list? nil] S F [0] F [list? (cons u S u S )] S F [0] F [list? f S ] S F [1] (f S nil and f S cons u S u S ) F [null? nil] S F [0] F [null? f S ] S F [1] (f S nil) F [num? n] S F [0] F [num? f S ] S F [1] (f S n) F [wrong string] S Error: string 25

34 Figure 2.19: The Scheme-Haskell operational semantics. F [sh k H (hs k H f S)] S F [f S ] F [sh L (hm L k M f M )] S F [wrong Bad value ] F [sh N n] S F [n] F [sh {k H } (nil t H )] S F [nil] F [sh {k H } (cons e H e H )] S F [cons (sh k H e H ) (sh {k H } e H )] F [sh (k H k H ) (λx H : t H.e H )] S F [λx S.sh k H ((λx H : t H.e H ) (hs k H x S ))] F [sh ( y H.k H ) (Λy H.e H )] S F [sh k H [L/y H ] e H [L/y H ]] 26

35 Figure 2.20: The Scheme-ML operational semantics. F [sm L (ms L f S )] S F [f S ] F [sm L (mh L k H e H )] S F [wrong Bad value ] F [sm N n] S F [n] F [sm {k M } (nil t M )] S F [nil] F [sm {k M } (cons u M u M )] S F [cons (sm k M u M ) (sm {k M } u M )] F [sm (k M k M ) f M ] S F [λx S.sm k M (f M (ms k M x S ))] F [sm ( y M.k M ) (Λy M.e M )] S F [sm k M [L/y M ] e M [L/y M ]] 27

36 Chapter 3 Proof of Type Soundness The proof of correctness is similar to that of Kinghorn [2], mutatis mutandis. Lemma 1. Inversion of the Typing Relation The syntactic forms of well-typed expressions determine the types of their subexpressions. Proof. Immediate from the typing rules. Lemma 2. Uniqueness of Types If e H, e M, and e S are well-typed then they have only one type. Proof. By structural induction on e H, e M, and e S and lemma 1. Lemma 3. Canonical Forms The syntactic forms of unforced values for each type. Proof. Immediate from the definitions of unforced values and the typing relations. 28

37 Theorem 2. Haskell Progress If H e H : t H then e H is an unforced value or e H e H or e H Error: string. Proof. By structural induction on e H and theorems 3 and 4. Theorem 3. ML Progress If M e M : t M then e M is an unforced value or e M e M or e M Error: string. Proof. By structural induction on e M and theorems 2 and 4. Theorem 4. Scheme Progress If S e S : TST then e S is an unforced value or e S e S or e S Error: string. Proof. By structural induction on e S and theorems 2 and 3. Lemma 4. Expression Substitution Preservation If Γ, x H : t H H e H : t H and Γ H e H : t H then Γ H e H [e H /x H ] : t H. If Γ, x M : t M M e M : t M and Γ M e M : t M then Γ M e M [e M /x M ] : t M. If Γ, x S : TST S e S : TST and Γ S e S : TST then Γ S e S [e S /x S] : TST. Proof. By structural induction. Lemma 5. Type Substitution Preservation If Γ, y H H e H : t H and Γ H t H then Γ H e H [t H /y H ] : t H [t H /y H ]. If Γ, y M M e M : t M and Γ M t M then Γ M e M [t M /y M ] : t M [t M /y M ]. Proof. By structural induction. Lemma 6. Evaluation Context Preservation 29

38 If H e H : t H, H e H : t H, and H F [e H ] H : t H then H F [e H ] H : t H. If M e M : t M, M e M : t M, and M F [e M ] M : t M then M F [e M ] M : t M. If S e S : TST, S e S : TST, and S F [e S ] S : TST then S F [e S ] S : TST. Proof. By structural induction. Theorem 5. Haskell Preservation If Γ H e H : t H and F [e H ] H F [e H ] then Γ H e H : t H. Proof. By cases on the reduction F [e H ] H F [e H ], lemma 6, and theorems 6 and 7. Theorem 6. ML Preservation If Γ M e M : t M and e M e M then Γ M e M : t M. Proof. By cases on the reduction F [e M ] H F [e M ], lemma 6, and theorems 5 and 7. Theorem 7. Scheme Preservation If Γ S e S : TST and e S e S then Γ S e S : TST. Proof. By cases on the reduction F [e S ] S F [e S ], lemma 6, and theorems 5 and 6. 30

39 Chapter 4 Conclusion Our method of interoperation resolves incompatible lazy and eager evaluation strategies transparently. The eager evaluation strategy mirrors the lazy one for reducible expressions inside the lazy language s boundaries in incompatible evaluation contexts common to both languages. Forced and unforced evaluation contexts and values comprise a simple framework that implements such a system. This method could be extended to resolve incompatible evaluation strategies for any pair of languages with common expressions. 31

40 Bibliography [1] M. Felleisen, R. B. Findler, and M. Flatt. Semantics Engineering with PLT Redex. The MIT Press, [2] D. L. Kinghorn. Preserving parametricity while sharing higher-order, polymorphic functions between scheme and ml. Master s thesis, California Polytechnic State University, San Luis Obispo, June [3] J. Matthews and R. B. Findler. Operational semantics for multi-language programs. SIGPLAN Not., 42(1):3 10,