Matthew Fluet Cornell University Greg Morrisett Harvard University

Slides:



Advertisements
Similar presentations
The Art of Avoiding Work
Advertisements

Introduction to Compilation of Functional Languages Wanhe Zhang Computing and Software Department McMaster University 16 th, March, 2004.
Type Checking, Inference, & Elaboration CS153: Compilers Greg Morrisett.
Exercise 1 Generics and Assignments. Language with Generics and Lots of Type Annotations Simple language with this syntax types:T ::= Int | Bool | T =>
Programming Languages and Paradigms
ML: a quasi-functional language with strong typing Conventional syntax: - val x = 5; (*user input *) val x = 5: int (*system response*) - fun len lis =
Prof. Necula CS 164 Lecture 141 Run-time Environments Lecture 8.
Chapter 5: Elementary Data Types Properties of types and objects –Data objects, variables and constants –Data types –Declarations –Type checking –Assignment.
1 Introduction to Computability Theory Lecture12: Reductions Prof. Amos Israeli.
Typed Assembly Languages COS 441, Fall 2004 Frances Spalding Based on slides from Dave Walker and Greg Morrisett.
A Lightning Tour of Haskell Lecture 1, Designing and Using Combinators John Hughes.
CS 536 Spring Run-time organization Lecture 19.
Tutorial 6 & 7 Symbol Table
ML: a quasi-functional language with strong typing Conventional syntax: - val x = 5; (*user input *) val x = 5: int (*system response*) - fun len lis =
1 Names, Scopes and Bindings. 2 Names Kinds of names Kinds of names Variables, functions, classes, types, labels, blocks, operators, tasks, etc. Variables,
Typed Memory Management in a Calculus of Capabilities David Walker (with Karl Crary and Greg Morrisett)
Elementary Data Types Scalar Data Types Numerical Data Types Other
Run-time Environment and Program Organization
 2002 Prentice Hall. All rights reserved. 1 Chapter 2 – Introduction to Python Programming Outline 2.1 Introduction 2.2 First Program in Python: Printing.
1 Chapter 5: Names, Bindings and Scopes Lionel Williams Jr. and Victoria Yan CSci 210, Advanced Software Paradigms September 26, 2010.
Chapter TwelveModern Programming Languages1 Memory Locations For Variables.
Types for Programs and Proofs Lecture 1. What are types? int, float, char, …, arrays types of procedures, functions, references, records, objects,...
CSC3315 (Spring 2009)1 CSC 3315 Programming Languages Hamid Harroud School of Science and Engineering, Akhawayn University
Compiler Construction
10/16/2015IT 3271 All about binding n Variables are bound (dynamically) to values n values must be stored somewhere in the memory. Memory Locations for.
December 8, 2003Other ISA's1 Other ISAs Next, we discuss some alternative instruction set designs. – Different ways of specifying memory addresses – Different.
1 Compiler Construction (CS-636) Muhammad Bilal Bashir UIIT, Rawalpindi.
Object-Oriented Programming Chapter Chapter
ISBN Object-Oriented Programming Chapter Chapter
CS 330 Programming Languages 10 / 23 / 2007 Instructor: Michael Eckmann.
ISBN Chapter 12 Support for Object-Oriented Programming.
LECTURE 10 Semantic Analysis. REVIEW So far, we’ve covered the following: Compilation methods: compilation vs. interpretation. The overall compilation.
Automatic Memory Management Without Run-time Overhead Brian Brooks.
Functional Programming
Object Lifetime and Pointers
EGR 2261 Unit 11 Pointers and Dynamic Variables
Run-Time Environments Chapter 7
Type Checking and Type Inference
Implementing Subprograms Chapter 10
Names and Attributes Names are a key programming language feature
Types for Programs and Proofs
Properties of Operations for Real Numbers
Type Checking, and Scopes
Database Management System
Containers and Lists CIS 40 – Introduction to Programming in Python
Run-time organization
PROGRAMMING IN HASKELL
Stateful Manifest Contracts
Names, Binding, and Scope
Matthew Fluet Cornell University
Expressions Chapter 4 Copyright © 2008 W. W. Norton & Company.
Type Systems for Region-based Memory Management
Unit IV Code Generation
Matthew Fluet Cornell University
Programming Languages and Compilers (CS 421)
Lecture 15 (Notes by P. N. Hilfinger and R. Bodik)
Memory Allocation CS 217.
Matthew Fluet Cornell University
PROGRAMMING IN HASKELL
Linear Regions Are All You Need
Resolution Proofs for Combinational Equivalence
Other ISAs Next, we’ll first we look at a longer example program, starting with some C code and translating it into our assembly language. Then we discuss.
Guest Lecture by David Johnston
UNIT V Run Time Environments.
Names and Binding In Text: Chapter 5.
Introduction to Data Structure
Data Structures & Algorithms
Course Overview PART I: overview material PART II: inside a compiler
Programming Languages and Compilers (CS 421)
Matthew Fluet Cornell University
Presentation transcript:

Matthew Fluet Cornell University Greg Morrisett Harvard University Monadic Regions Matthew Fluet Cornell University Greg Morrisett Harvard University

Introduction Draw together two lines of research

Introduction Draw together two lines of research Region-based memory management [Tofte & Talpin 94] Regions delimit lifetimes of objects Monadic encapsulation of effects [Launchbury & Peyton Jones 94] Embed imperative features in pure languages

Introduction Region-based memory management [T-T 94] Regions delimit lifetimes of objects

Introduction Region-based memory management [T-T 94] letregion r in e Regions delimit lifetimes of objects letregion r in e LIFO lifetimes following the block structure of the program Region \rho is a distinguished area of memory holding heap allocated data. During the evaluation of e, data can be allocated in \rho. After e is reduced to a value, the entire region \rho can be reclaimed.

Introduction Region-based memory management [T-T 94] Regions delimit lifetimes of objects Type-and-effects system ensures safety

Introduction Region-based memory management [T-T 94] Regions delimit lifetimes of objects Type-and-effects system ensures safety But adds complications:

Introduction Region-based memory management [T-T 94] Regions delimit lifetimes of objects Type-and-effects system ensures safety But adds complications:

Introduction Region-based memory management [T-T 94] Regions delimit lifetimes of objects Type-and-effects system ensures safety But adds complications: Typing rule for letregion is subtle (due to the interplay of dangling pointers and effects) Region polymorphism and region subtyping (and region variables and region kinds) Effects correspond to sets of regions (so term equality no longer suffices for type checking) All of these aspects make the meta-theory more complicated than that of many type systems.

Introduction Monadic encapsulation of effects [L-PJ 94] Embed imperative features in pure languages

Introduction Monadic encapsulation of effects [L-PJ 94] Embed imperative features in pure languages Types ST s a STRef s a Operations returnST :: 8s,a. a ! ST s a thenST :: 8s,a,b. ST s a ! (a ! ST s b) ! ST s b newSTRef :: 8s,a. a ! ST s (STRef s a) readSTRef :: 8s,a. STRef s a ! ST s a writeSTRef :: 8s,a. STRef s a ! a ! ST s () Embed stateful computations -- for example, mutable variables. ST corresponds to computation over a store abstracted by s. The computation can allocate, read, and write mutable variables in the store.

Introduction Monadic encapsulation of effects [L-PJ 94] Embed imperative features in pure languages runST :: 8a. (8s. ST s a) ! a Polymorphism over store index type ensures that the computation (and the result) are independent of the initial (and final) store runST corresponds to executing the computation in an empty store.

Introduction Monadic encapsulation of effects [L-PJ 94] Embed imperative features in pure languages Polymorphic type system ensures safety

Introduction Monadic encapsulation of effects [L-PJ 94] Embed imperative features in pure languages Polymorphic type system ensures safety Well understood meta-theory Plain old polymorphism suffices.

Introduction Encode region-based language in System F with monadic sub-language Features Best of both worlds Power of region-based memory management Simplicity of System F type system Plain old polymorphism suffices.

Introduction Encode region-based language in System F with monadic sub-language Features ST monad and runST serve as inspiration Region polymorphism and region subtyping (proof) terms that witness subtyping Type- and meaning-preserving translation Plain old polymorphism suffices.

Outline Introduction FRGN and RGN monad Translation Conclusion

FRGN = System F + RGN monad Monadic sub-language

RGN monad: Types Monadic types

RGN monad: Types Monadic types RGN r t – computations in region r returning values of type t “in region r” means the computation a will allocate data in and read data from a region, denoted by the type variable r. RGN is the “region monad,” as ST was the “state monad.”

RGN monad: Types Monadic types RGN r t – computations in region r returning values of type t RGNVar r t – values of type t allocated in region r

RGN monad: Operations Monadic unit and bind returnRGN :: 8a,r. a ! RGN r a thenRGN :: 8a,b,r. RGN r a ! (a ! RGN r b) ! RGN r b returnRGN takes a value and gives the trivial computation (that does nothing with the region). thenRGN sequences two computations; the second has access to the value computed by the first.

RGN monad: Operations Monadic unit and bind returnRGN :: 8a,r. a ! RGN r a thenRGN :: 8a,b,r. RGN r a ! (a ! RGN r b) ! RGN r b Note that the operation allows the type of the value computed to change …

RGN monad: Operations Monadic unit and bind returnRGN :: 8a,r. a ! RGN r a thenRGN :: 8a,b,r. RGN r a ! (a ! RGN r b) ! RGN r b … but not the region of the computation.

RGN monad: Operations Create and read region allocated values newRGNVar :: 8a,r. a ! RGN r (RGNVar r a) readRGNVar :: 8a,r. RGNVar r a ! RGN r a Two operators for manipulating region allocated data.

RGN monad: Operations Create and read region allocated values newRGNVar :: 8a,r. a ! RGN r (RGNVar r a) readRGNVar :: 8a,r. RGNVar r a ! RGN r a As expected, the regions must match up.

RGN monad: Encapsulation Encapsulate and run a monadic computation runRGN :: 8a. (8r. RGN r a) ! a We can mimic runST.

RGN monad: Encapsulation Encapsulate and run a monadic computation runRGN :: 8a. (8r. RGN r a) ! a

RGN monad: Encapsulation Encapsulate and run a monadic computation runRGN :: 8a. (8r. RGN r a) ! a Note that quantification over the region means no assumptions. “for all regions” ) no assumptions about region

RGN monad: Encapsulation Encapsulate and run a monadic computation runRGN :: 8a. (8r. RGN r a) ! a “for all regions” ) no assumptions about region

RGN monad: Encapsulation Encapsulate and run a monadic computation runRGN :: 8a. (8r. RGN r a) ! a In particular, the result cannot be a RGNVar r. “for all regions” ) no assumptions about region result is independent of region ) r 62 ftv(a) ) region values don’t escape

RGN monad: Sufficient?? That was easy … too easy … So far, I haven’t done anything more than copy the ST monad. I wouldn’t be here today if there weren’t more to the story…

RGN monad: Sufficient?? That was easy … too easy … letregion r1 in let a = 1 at r1 in let c = letregion r2 in let b = 7 at r2 in (a + b) at r1 in … c … Here is a canonical example of region based memory-management usage. r1

input allocated in first region RGN monad: Sufficient?? That was easy … too easy … letregion r1 in let a = 1 at r1 in let c = letregion r2 in let b = 7 at r2 in (a + b) at r1 in … c … Input to a computation is allocated in one region … r1 a : 1 input allocated in first region

input allocated in first region RGN monad: Sufficient?? That was easy … too easy … letregion r1 in let a = 1 at r1 in let c = letregion r2 in let b = 7 at r2 in (a + b) at r1 in … c … r2 To perform the computation, we enter a second region … r1 a : 1 input allocated in first region

RGN monad: Sufficient?? That was easy … too easy … letregion r1 in let a = 1 at r1 in let c = letregion r2 in let b = 7 at r2 in (a + b) at r1 in … c … r2 temporary allocated in second region b : 7 Temporary data used by the computation are allocated in the second region … r1 a : 1 input allocated in first region

RGN monad: Sufficient?? That was easy … too easy … letregion r1 in let a = 1 at r1 in let c = letregion r2 in let b = 7 at r2 in (a + b) at r1 in … c … r2 temporary allocated in second region b : 7 The output of the computation is allocated in the first region (where it will be accessible) … r1 a : 1 input and output allocated in first region c : 8

RGN monad: Sufficient?? That was easy … too easy … letregion r1 in let a = 1 at r1 in let c = letregion r2 in let b = 7 at r2 in (a + b) at r1 in … c … temporary allocated in second region But the temporary data is reclaimed when the computation is done. r1 a : 1 input and output allocated in first region c : 8

RGN monad: Sufficient?? That was easy … too easy … letregion r1 in let a = 1 at r1 in let c = letregion r2 in let b = 7 at r2 in (a + b) at r1 in … c … Let’s try a naïve translation to the RGN monad …

RGN monad: Sufficient?? That was easy … too easy … letregion r1 in let a = 1 at r1 in let c = letregion r2 in let b = 7 at r2 in (a + b) at r1 in … c … runRGN ( Lr1. do a à newRGNVar [r1] 1 c à runRGN ( Lr2. do b à newRGNVar [r2] 7 z à a © b newRGNVar [r1] z ) … c … )

RGN monad: Sufficient?? That was easy … too easy … runRGN ( Lr1. do a à newRGNVar [r1] 1 c à runRGN ( Lr2. do b à newRGNVar [r2] 7 z à a © b newRGNVar [r1] z ) … c … ) Note that this uses the Haskell “do” notation; the  symbol corresponds to the thenRGN operation. There are a variety of things wrong with this translation. I’m going to touch on one in particular …

RGN monad: Sufficient?? That was easy … too easy … runRGN ( Lr1. allocating in younger region requires RGN r2 t type runRGN ( Lr1. do a à newRGNVar [r1] 1 c à runRGN ( Lr2. do b à newRGNVar [r2] 7 z à a © b newRGNVar [r1] z ) … c … ) Note that allocating in the younger region will result in a computation in region r2, while allocating the result in the older region will result in a computation in region r1. Since these two computations must be sequenced, there is a mismatch. allocating in older region requires RGN r1 t type

RGN monad: Sufficient?? That was easy … too easy … runRGN ( Lr1. do a à newRGNVar [r1] 1 c à runRGN ( Lr2. do b à newRGNVar [r2] 7 z à a © b newRGNVar [r1] z ) … c … )

RGN monad: Sufficient?? That was easy … too easy … because the younger region is not independent of the older region letregion r1 in let a = 1 at r1 in let c = letregion r2 in let b = 7 at r2 in (a + b) at r1 in … c …

RGN monad: Sufficient?? That was easy … too easy … because the younger region is not independent of the older region letregion r1 in let a = 1 at r1 in let c = letregion r2 in let b = 7 at r2 in (a + b) at r1 in … c … {r2} µ {r1,r2} There is an implicit subtyping going on in the region calculus that allows us to view the effect of allocating the temporary and the result as being the union of the two regions involved. This subsumption and treatment of effects as sets is the real obstacle to overcome in the encoding. {r1} [ {r2} [ {r1} µ {r1,r2}

RGN monad: Nested regions Encapsulate a nested region? nestRGN :: 8a,r. (8s. RGN (r £ s) a) ! RGN r a liftRGN :: 8a,r,s. (RGN r a) ! RGN (r £ s) a Here is one “solution” which also has its roots in the ST monad. The idea is to explicitly nest one computation in another. The “type” of the younger region is related to that of the older region and that connection allows us to lift computations that “really” belong in the older region into the younger region. This is safe, because the older region outlives the younger region – when we run the computation, if we ever enter the younger region, we must have previously entered the older region.

RGN monad: Nested regions Encapsulate a nested region? nestRGN :: 8a,r. (8s. RGN (r £ s) a) ! RGN r a liftRGN :: 8a,r,s. (RGN r a) ! RGN (r £ s) a encode stack of regions using product type

RGN monad: Nested regions Encapsulate a nested region? nestRGN :: 8a,r. (8s. RGN (r £ s) a) ! RGN r a liftRGN :: 8a,r,s. (RGN r a) ! RGN (r £ s) a encode stack of regions using product type import computation from an older region into the younger region

RGN monad: Nested regions Encapsulate a nested region? runRGN ( Lr1. do a à newRGNVar [r1] 1 c à nestRGN ( Lr2. do b à newRGNVar [r2] 7 z à a © b liftRGN (newRGNVar [r1] z) ) … c … )

RGN monad: Nested regions Encapsulate a nested region? runRGN ( Lr1. do a à newRGNVar [r1] 1 c à nestRGN ( Lr2. do b à newRGNVar [r2] 7 z à a © b liftRGN (newRGNVar [r1] z) ) … c … ) This takes care of one issue I raised. (There are others.) But, is this good enough? More importantly, is it the right abstraction?

RGN monad: Nested regions Let’s write a generic adding function To answer that, let’s consider another problem. We wish to write a generic adding function – take two region allocated integers and return their sum as a freshly allocated region integer. It is generic because this function should work for arbitrary input and output regions.

RGN monad: Nested regions Let’s write a generic adding function gadd :: 8r1,r2,r3,r4. RGNVar r1 Int ! RGNVar r2 Int ! £ RGN r4 (RGNVar r3 Int) £ So, we want a function with this sort of type. Note that the result must be a region computation, because the function will read and allocate variables. We know we’ll need some instances of liftRGN to sequence the operations …

RGN monad: Nested regions Let’s write a generic adding function gadd :: 8r1,r2,r3,r4. RGNVar r1 Int ! RGNVar r2 Int ! £ RGN r4 (RGNVar r3 Int) £ gadd a b = liftRGN ( do x à readRGNVar a y à liftRGN (readRGNVar b) liftRGN (liftRGN (newRGNVar (x + y))) ) … but we’ll always end up with a less generic function than we want.

RGN monad: Nested regions Let’s write a generic adding function gadd :: 8r1,r2,r3,r4. RGNVar (r1 £ r2 £ r3) Int ! RGNVar (r1 £ r2) Int ! RGN (r1 £ r2 £ r3 £ r4) (RGNVar r1 Int) gadd a b = liftRGN ( do x à readRGNVar a y à liftRGN (readRGNVar b) liftRGN (liftRGN (newRGNVar (x + y))) ) We’ve enforced a total order, when we only need a partial order.

RGN monad: Nested regions Let’s write a generic adding function gadd lift1 lift2 lift3 a b = 8 do x à lift1 (readRGNVar a) y à lift2 (readRGNVar b) lift3 (newRGNVar (x + y)) One way around this is to abstract over the liftRGN applications. The caller knows how the 4 regions are related, so it can provide the right lifting functions.

RGN monad: Nested regions Let’s write a generic adding function gadd :: 8r1,r2,r3,r4. (8b. RGN r1 b ! RGN r4 b) ! (8b. RGN r2 b ! RGN r4 b) ! (8b. RGN r3 b ! RGN r4 b) ! RGNVar r1 Int ! RGNVar r2 Int ! RGN r4 (RGNVar r3 Int) We’ve generalized the type of gadd …

RGN monad: Nested regions Let’s write a generic adding function gadd :: 8r1,r2,r3,r4. (8b. RGN r1 b ! RGN r4 b) ! (8b. RGN r2 b ! RGN r4 b) ! (8b. RGN r3 b ! RGN r4 b) ! RGNVar r1 Int ! RGNVar r2 Int ! RGN r4 (RGNVar r3 Int) … but it turns out that this is the right abstraction.

RGN monad: Region evidence Encapsulate a region letRGN :: 8a,r. (8s. r ¹ s ! RGN s a) ! RGN r a Rather than making the relation explicit in the product type, we make it implicit in a witness type – witnessing the subtyping relation between the older and younger region.

RGN monad: Region evidence Encapsulate a region letRGN :: 8a,r. (8s. r ¹ s ! RGN s a) ! RGN r a witness : evidence that r is a sub-region of s

RGN monad: Region evidence Exploiting evidence letRGN :: 8a,r. (8s. r ¹ s ! RGN s a) ! RGN r a liftRGN :: 8b,r,s. r ¹ s ! RGN r b ! RGN s b This evidence can be used to lift computations …

RGN monad: Region evidence Exploiting evidence letRGN :: 8a,r. (8s. r ¹ s ! RGN s a) ! RGN r a liftRGN :: 8b,r,s. r ¹ s ! RGN r b ! RGN s b liftRGNVar :: 8b,r,s. r ¹ s ! RGNVar r b ! RGNVar s b … or even region allocated variables. Note that each of these is operationally an identity function. It is just compile-time evidence that interpreting computations or variables in a different way is safe.

RGN monad: Region evidence Encapsulate a region letRGN :: 8a,r. (8s. r ¹ s ! RGN s a) ! RGN r a r ¹ s  8b. RGN r b ! RGN s b

RGN monad: Region evidence Encapsulate a region letRGN :: 8a,r. (8s. r ¹ s ! RGN s a) ! RGN r a r ¹ s  8b. RGN r b ! RGN s b witness function : evidence that r is a sub-region of s

RGN monad: Region evidence Encapsulate a region gadd :: 8r1,r2,r3,r4. (r1 ¹ r4) ! (r2 ¹ r4) ! (r3 ¹ r4) ! RGNVar r1 Int ! RGNVar r2 Int ! RGN r4 (RGNVar r3 Int) gadd w1¹4 w2¹4 w3¹4 a b = 8 do x à w1¹4 (readRGNVar a) y à w2¹4 (readRGNVar b) w3¹4 (newRGNVar (x + y))

RGN monad: Region evidence Encapsulate a region runRGN ( Lr1. do a à newRGNVar [r1] 1 c à letRGN ( Lr2. lw1¹2. do b à newRGNVar [r2] 7 gadd w1¹2 id id a b ) … c … )

Outline Introduction FRGN and RGN monad Translation Conclusion Single Effect Calculus Translation properties Conclusion

Single Effect Calculus LIFO stack of regions imposes a partial order on live (allocated) regions Older regions outlive younger regions A single region can serve as the representative for a set of effects Region appears as a single effect in place of the set

Translation Type- and meaning-preserving translation from Region Calculus to Single Effect Calculus

Translation Type- and meaning-preserving translation from Region Calculus to Single Effect Calculus « ((Int,r1) ! (Int,r3), r) ¬ ) {r1,r2,r3}

(Pr º {r1,r2,r3}.r ((Int,r1) ! (Int,r2), r), r) Translation Type- and meaning-preserving translation from Region Calculus to Single Effect Calculus « ((Int,r1) ! (Int,r3), r) ¬ ) (Pr º {r1,r2,r3}.r ((Int,r1) ! (Int,r2), r), r) {r1,r2,r3} r

(Pr º {r1,r2,r3}.r ((Int,r1) ! (Int,r2), r), r) Translation Type- and meaning-preserving translation from Region Calculus to Single Effect Calculus « ((Int,r1) ! (Int,r3), r) ¬ ) (Pr º {r1,r2,r3}.r ((Int,r1) ! (Int,r2), r), r) {r1,r2,r3} r

(Pr º {r1,r2,r3}.r ((Int,r1) ! (Int,r2), r), r) Translation Type- and meaning-preserving translation from Region Calculus to Single Effect Calculus « ((Int,r1) ! (Int,r3), r) ¬ ) (Pr º {r1,r2,r3}.r ((Int,r1) ! (Int,r2), r), r) {r1,r2,r3} r

Translation Type- and meaning-preserving translation from Single Effect Calculus to FRGN

Translation Type- and meaning-preserving translation from Single Effect Calculus to FRGN « t1 ! t2 ¬ ) «t1¬ ! RGN r «t2¬ r

Translation Type- and meaning-preserving translation from Single Effect Calculus to FRGN « t1 ! t2 ¬ ) «t1¬ ! RGN r «t2¬ r

Translation Type- and meaning-preserving translation from Single Effect Calculus to FRGN « t1 ! t2 ¬ ) «t1¬ ! RGN r «t2¬ r

8r. (r1 ¹ r £ r2 ¹ r £ r3 ¹ r) ! RGN r «t¬ Translation Type- and meaning-preserving translation from Single Effect Calculus to FRGN « t1 ! t2 ¬ ) «t1¬ ! RGN r «t2¬ « Pr º {r1,r2,r3}.r t ¬ ) 8r. (r1 ¹ r £ r2 ¹ r £ r3 ¹ r) ! RGN r «t¬ r

8r. ((r1 ¹ r) £ (r2 ¹ r) £ (r3 ¹ r)) ! RGN r «t¬ Translation Type- and meaning-preserving translation from Single Effect Calculus to FRGN « t1 ! t2 ¬ ) «t1¬ ! RGN r «t2¬ « Pr º {r1,r2,r3}.r t ¬ ) 8r. ((r1 ¹ r) £ (r2 ¹ r) £ (r3 ¹ r)) ! RGN r «t¬ r

8r. ((r1 ¹ r) £ (r2 ¹ r) £ (r3 ¹ r)) ! RGN r «t¬ Translation Type- and meaning-preserving translation from Single Effect Calculus to FRGN « t1 ! t2 ¬ ) «t1¬ ! RGN r «t2¬ « Pr º {r1,r2,r3}.r t ¬ ) 8r. ((r1 ¹ r) £ (r2 ¹ r) £ (r3 ¹ r)) ! RGN r «t¬ r

«letregion r in e¬ ) letRGN (Lr.lwr. «e¬) Translation Type- and meaning-preserving translation from Single Effect Calculus to FRGN «letregion r in e¬ ) letRGN (Lr.lwr. «e¬)

Translation Type- and meaning-preserving translation from Single Effect Calculus to FRGN Coherence Lemma: Translating a SEC subtyping derivations yields a function operationally equivalent to the identity function.

Related Work [Banerjee, Heintze, & Riecke 99] [Wadler & Thiemann 03] Nontrivial theory of equality on types

Future Work Can RGN monad be made more palatable? Use type classes to infer witness functions

Conclusion Monadic encoding of effects applicable to region calculi Translation provides a more modular account of the soundness of region based languages Effects encoded by bounded region subtyping Subtyping eliminated by a coercion-based interpretation Encapsulation using only parametric polymorphism Trivial (syntactic) equality on types