Modal Types for Mobile Code (Thesis Proposal)tom7/proposal/proposal.pdfModal Types for Mobile Code (Thesis Proposal) ∗ Tom Murphy VII March 13, 2006 Abstract Modal logic is a family

Modal Types for Mobile Code(Thesis Proposal) ∗

Tom Murphy VII

March 13, 2006

Abstract

Modal logic is a family of logics with the ability to simultaneously rea-son about truth from multiple perspectives. Our previous work showedhow the modal logic Intuitionistic S5 could form the basis for a simplelambda calculus for spatially distributed programs. I propose here a the-sis project to demonstrate the efficacy and elegance of modal type systemsfor controlling spatially distributed resources in a programming language.The project has strong components of both theory and practice: the designof ML5, a new programming language for distributed computing, and itsimplementation. I present technical details for the language and imple-mentation where they have been completed, and a plan for the work to bedone where they have not.

1 Introduction

This research seeks to demonstrate that modal type systems provide an elegantand practical way to control spatially distributed resources in mobile computerprograms. I propose to do this by designing and implementing a programminglanguage with a modal type system. I will then demonstrate the language andimplementation’s effectiveness by building an example distributed applicationin the language.

The work is part of a larger research program, called ConCert, which isbuilding a large-scale peer-to-peer “Grid Computing” platform based on certi-fied code technology. For this proposal, I will begin by describing the currentdesign of ConCert, which will serve to motivate the thesis work and argue formy qualifications to undertake the proposed research. I will then demonstratehow modal types are an appropriate tool for reasoning about spatial distri-bution, by reviewing a foundational calculus we developed [31, 30] based onmodal logic. Given the problem and an appropriate tool, I then present the de-sign for a new programming language for distributed computing called ML5.

∗The ConCert Project is supported by the National Science Foundation under grant ITR/SY+SI 0121633:“Language Technology for Trustless Software Dissemination”.

1

Before going into these items in detail, a high-level summary of each pointshould serve to provide the necessary context to understand what follows.

1.1 Overview

ConCert. The ConCert project’s goal is to build a large-scale peer-to-peerdistributed network for trustless Grid computing [11]. Grid computing [18],which is named by analogy with electric power grids, is the practice of cou-pling diverse computational resources into a large shared computer. In thissetting, code moves around the network, which presents a security issue: Howdoes a code consumer know that a piece of code is safe to run? There are sev-eral functioning Grid computing systems already deployed [17, 3], and eachrelies on the establishment of trust relationships between the code producerand code consumer to address this security issue. In the ConCert system, weallow for the trustless dissemination of code by using certified code technol-ogy [32]. To achieve this, each piece of mobile code comes with a certificatedemonstrating the relevant properties of the code. These are intrinsic proper-ties of the code (e.g., its type safety) rather than the extrinsic properties (e.g.,who wrote it) sometimes certified by cryptographic signatures.

The implementation of the proposed language, ML5, should also work byproducing safety certificates. I will do this by building a type-directed certify-ing compiler [27, 35]. This means that the implementation must be carefullydesigned (see Section 6), but doing so has many research and engineering ben-efits.

Grid/ML. Grid/ML [29] is a high-level language that can be used to producecertified code for use on the ConCert network. It is a functional language basedon Standard ML [24] with primitives for Grid computing. In Grid/ML, the pro-grammer writes his whole Grid application as a single program. This programis made of two parts: the client, which runs only on the user’s computer andinteracts with him, and the mobile code, which runs on arbitrary hosts in thenetwork.

Grid/ML is practical for a certain class of problems, and has been usedfor a few Grid programming experiments [12]. However, it has two majorshortcomings. First, the mobile code is agnostic to where it is running, and soapplications must treat the hosts in the network uniformly; it is not possible tomake use of special resources only available at certain sites. Since distributedcomputing is often motivated by the desire to make use of resources other thanmere processing power, this rules out an important set of applications.

Second, even with the assumption of uniformity, Grid/ML still has a dis-tinction between client code and mobile code. Certain operations, such as I/O,can only be performed on the client and result in run-time failure if used inmobile code.

My solution to both problems is to enrich the ML type system with a con-cept of place. By doing so, the language will be able to support location-aware

2

programming, so that network locations need not be treated uniformly. As aconsequence, the client will be a place like any other, and we will be able to dis-tinguish its capabilities from the capabilities of other hosts. Because we use atype system, we can make these distinctions statically, excluding errors beforethe program is ever run.

Modal logic and modal types. Type systems for functional languages likeML have a close connection to logic, called the Curry-Howard isomorphism.Under this view, the propositions of intuitionistic logic are interpreted as thetypes of a programming language. Proofs of propositions then become pro-grams inhabiting those types. Different logics, viewed through the lens of theCurry-Howard isomorphism, give rise to a variety of elegant and useful typesystems for programming languages.

In order to develop a type system with a notion of place, we use a logic withthe ability to reason spatially, namely modal logic [23]. The propositional logicupon which ML is based is concerned with the truth of propositions from a sin-gle universal viewpoint. Modal logic introduces the concept of truth from mul-tiple different perspectives, which are called “worlds.” The logic is then able toreason simultaneously about truth in these worlds. Under the Curry-Howardview, these worlds become hosts in the network, and so our type system iscorrespondingly endowed with a notion of place.

Distributed programming with modal types. Because a proof in modal logiccontains reasoning from multiple different worlds, programs in our modal pro-gramming language span multiple hosts. That is, each program consists of aseries of nested expressions to be evaluated at various hosts in the network.These fragments make reference to the other sites in the network, and the re-sources particular to those sites. The main purpose of the type system is totrack these references to remote resources so that they are only used in a safeway: Localized resources can only be used in the correct place. When code ordata do not depend on their location, we are also able to indicate this in thetype system. This allows them to be safely used anywhere. The main result oftype safety of the language is that resources are only used in the correct place.This brings us to the thesis statement:

Thesis Statement. Modal type systems provide an elegant andpractical way to control spatially distributed resources in mobilecomputer programs.

Although modal types naturally address spatial distribution, this is onlyone facet of distributed computing. In particular, a logical approach to con-currency and failure is beyond the scope of this thesis. However, the languagewill need to have basic support for these features in order to create a realisticapplication.

3

Implementation. The implementation of ML5 will consist of a type-directedcompiler for the language and a distributed runtime system. The compiler isresponsible for translating the high-level language into certified machine code.The runtime’s primary task is to form the network of hosts on which the dis-tributed programs run. To do this, it must be able to marshal code and datainto raw bytes so that they can be transmitted on the network. In order toensure safety, the marshalled representation must be accompanied by a cer-tificate demonstrating its well-formedness. It is the runtime’s responsibility toverify these certificates upon receipt, relative to the host’s specific set of localresources. As the marshalled bytes are reconstituted into code and data, refer-ences to those local resources become linked to them.

The runtime has a few other responsibilities: it performs distributedgarbage collection to reclaim resources, and provides rudimentary support forfailure detection and concurrency (Section 7).

Application. To demonstrate the usefulness of the language and implemen-tation, I will use it to build an example distributed application. Before choosingan appropriate application, I will need to have a better idea of how the lan-guage supports features like concurrency. Thus, this proposal does not committo a specific application.

This concludes the high-level summary. The remainder proceeds as fol-lows: I begin by explaining the proposed work in depth using the same outlineas above (Sections 2–8). For the language design, I give both informal codeexamples and formal semantics for a simplified subset of the language. Forthe implementation of the compiler, I give formal translations for the core lan-guage constructs; these translations need only be extended to support a morefull-featured language. For the compiler’s back-end and runtime, I outline theresearch problems that still need to be solved. I conclude with a comparison toother languages for distributed computing (Section 9), and a timeline for thecompletion of the thesis work (Section 10).

2 ConCert

The current ConCert system is designed to harness one specific resource: idleCPU power from a large network of volunteered computers. A program de-signed to be run on ConCert is broken up into pieces of independent mobilecode (called “cords”) that may run in parallel. To the programmer, ConCertacts as a single, highly parallel computer with simple primitives for fork-joinparallelism (see below).

A computer becomes part of the ConCert network by running a piece ofsoftware called the Conductor. The Conductor is responsible for maintainingcontact with its peers, and for allocating cords to idle computers in order tobe executed. This allocation is done using a “work-stealing” model: Each hostmaintains a queue of cords that are ready to be executed, and when a host is

4

idle, it “steals” work out of the queues of other hosts. This model is efficient [5],but because the location in which a cord will eventually run depends on theidle status of the machines in the network, it is not possible for the program-mer to know in advance where his code will run. Moreover, to support faulttolerance (by restarting failed cords), a cord must be able to be run multipletimes in different places and always produce the same result.

As a consequence, we provide cords with a uniform view of the network—a cord cannot tell what host it is running on, nor can it access any of that host’slocal resources like permanent storage and I/O. This is acceptable because theonly resource ConCert seeks to harness is idle CPU power. In contrast, theproposed work will allow programs to make use of any sort of distributedresource.

Adding language support for such local resources is tricky. To illustratesome of the issues, we look at a simple Grid/ML program.

letval f = openfile "numbers.txt"val f2 = openfile "factors.txt"

(* append the list l to the output file *)fun writeresult l =

write(f2, nums-to-string l ˆ "\n")

val inputs = readfile f

(* prime factorization of n for n > 0 *)fun factor n =

letfun trial 1 = n :: nil

| trial m = if n mod m = 0then factor m @ factor (n div m)else trial (m - 1)

intrial (floor (sqrt (real n)))

end

val cords =map (fn n => submit (fn () => factor n)) inputs

val results = waitall cordsin

app writeresult resultsend

This Grid/ML program1 computes the prime factorizations of the numbers

1The example takes the liberty of assuming the existence of some library code, for instance

5

in the file "numbers.txt" and writes those to the file "factors.txt" (bothfiles reside on the client). It does this by creating a cord for each factoring taskand submitting them to the local work queue with the primitive submit . TheGrid/ML primitives used have these types:

submit : (unit → α) → α cordwaitall : α cord list → α list

A value of type α cord is a running computation that returns a result oftype α. Grid/ML allows α to be instantiated with any type. In this case eachjob is an int list cord . After submitting the cords, the program then waitsfor them all to complete, and writes the results to the output file.

The file I/O that the program performs is an effect. Such effects are allowedonly in the part of the Grid/ML program that runs on the client. This is becauseI/O interacts with the external world, and so it depends on the place in whichthe code is executed. Therefore, an effect inside cord code would violate therequirement that it be agnostic about the host on which it runs. In Grid/ML,such errors are detected only at run-time. For example, if we modify the pro-gram so that the body of factor tries to write to the file f2 or read from thefile f , then the program will abort at that operation. Although both files are inscope, the file descriptors do not make sense when executing at remote sites—even if we wanted to allow I/O in cord code, we would not be able to accessthose files once execution has left the client.

This does not necessarily mean that open file descriptors cannot ever leavethe client. Suppose the program is modified to be higher-order:

let(* ... *)

fun factor n =let

(* ... *)val factors = trial (floor (sqrt (real n)))

in(fn () => writeresult factors)

end

(* ... *)in

app (fn g => g ()) resultsend

Now, instead of returning the list of factors directly, each cord returns afunction that writes the result to the file on the client. The client consumes theseresults by calling the functions. (Writing the program this way is gratuitous

nums-to-string and readfile .

6

here, but higher-order mobile code is often genuinely useful!) This programhas the same behavior as the first version. The reference to the local file safelymakes a round trip from the client to the cord code and back in the environmentof each function. Thus it is not the references themselves that we need to tame,but the way those references to local resources are used. To do this, the typesystem of ML5 will associate a place with each value, and then only allow avalue to be consumed in that same place. However, values will be able to flowfreely between places otherwise.

Associating a place with each value does ensure safety, but it can excludetoo many programs; many values are actually portable to every location. Wedo not want such values to be unnecessarily restricted to the place where theyare created. For example, in the program above the factor function refers tothe functions sqrt and @, which are defined as part of the standard library onthe client. This is safe because these functions do not use any local resources.An important feature of the ML5 type system is that it also accounts for valueslike these that can be used anywhere. Using these features the ML5 type systemwill allow us to statically typecheck both the original program and the higher-order version.

We have now motivated a type system enhanced with a notion of place.To summarize, the type system for ML5 will ensure that localized resourcesare only used in the correct place by associating with each sub-expression theplace in which it will be evaluated, and associating with each bound variablethe place where it may be used. We will also introduce support for bindingsthat are usable in any place, since this is very common. The foundation of thistype system comes from modal logic, which is introduced in the next section.

3 Modal Logic

“Modal logic” refers to a family of logics with the ability to reason about truthfrom multiple simultaneous perspectives. For this proposal, we will start withthe specific modal logic called Intuitionistic S5 and then extend it to suit ourpurposes. IS5 is most easily understood as an extension of Intuitionistic logic,whose basic judgment is

Γ ` A true

where A is a proposition and Γ is a collection of hypotheses of the form B truefor various propositions B. The judgment asserts that the proposition A is true,from a single universal viewpoint, assuming that the hypotheses in Γ are alsotrue.

IS5 changes this judgment by indexing the notion of truth by a collection of“possible worlds.” These possible worlds are the different perspectives fromwhich we judge the truth of propositions. All possible worlds must indeed bepossible (they must not admit logical contradictions), but otherwise can dis-agree on what facts are true. As a real world example, in some possible worlds

7

the proposition “it is raining in Pittsburgh” is true and in others it is not. How-ever, in no possible world is “it is raining in Pittsburgh and it is not raining inPittsburgh” true. Modal logic gives us the ability to state that a proposition istrue in some specific possible world. The basic judgment in IS5 is:

Γ ` A true@w

where A is a proposition as before and w is a world. This judgment assertsthat, assuming the hypotheses in Γ, the proposition A is true in the world w.World expressions w include both constants w standing for specific worlds,and world variables, written ω. Truth in IS5 is always with respect to a world.The context Γ therefore consists of assumptions of the form B true@w′.

Most of the rules from intuitionistic logic are imported into IS5, with thejudgment simply changed from true to true@w. For example, we reason aboutconjunction as before:

Γ ` A true@w Γ ` B true@wΓ ` A ∧B true@w

∧ IΓ ` A ∧B true@w

Γ ` A true@w∧ E1

To conclude A∧B at the world w, we must conclude both A and B at that sameworld. Likewise, if we know A ∧B at w, then we know A at that same world.

There are also two new connectives, which both use the indexed truth judg-ment in interesting ways. The first is 2 (read “box”), where 2A means that Ais true in all possible worlds. The rules for 2 are:

Γ, ω world ` A true@ω

Γ ` 2A true@w2 I

Γ ` 2A true@wΓ ` A true@w′ 2 E

Because the meaning of 2A is that A is true in every world, we may concludefrom 2A at some world w the proposition A at any world w′ (rule 2 E). Toprove that a proposition is true in every world (rule 2 I), we must prove thatthe proposition A is true at a new hypothetical world ω about which nothing isknown. This world variable is bound in Γ.

The other new connective is 3 (read “diamond”). The proposition 3Ameans that A is true in some possible world. The 3 connective is defined asfollows:

Γ ` A true@w′

Γ ` 3A true@w3 I

Γ ` 3A true@w′ Γ, ω world, A true@ω ` C true@wΓ ` C true@w

3 E

To prove 3A at w, we require a proof of A in any world w′ (rule 3 I). To con-sume a proof of 3A (rule 3 E), we get to assume the existence of some world(about which nothing else is known) where A is true, in order to continue prov-ing some other proposition C. The elimination of 3A happens at a differentworld (w′) than the remainder of the reasoning (w). In our computational in-terpretation (Section 4), these worlds will be thought of as hosts in the network,and so this rule incurs a sort of “action at a distance” by involving two hosts inthe operation. There, we will use a different but equivalent formulation of therules that isolates this network communication to a single rule.

8

The at modality. The 2 and 3 connectives are the only new modalities ofIntuitionistic S5. Our first extension to the logic adds a third modality, at. Theproposition A atw means that A is true at the world w; it is a direct internaliza-tion of the judgment A true@w as a proposition [20, 21]. Such internalizationsare very common. For instance, implication (A ⊃ B) in propositional logic isthe internalization of the hypothetical judgment (A true ` B true). The rulesdefining the connective are:

Γ ` A true@w′

Γ ` A atw′ true@wat I

Γ ` A atw′ true@wΓ ` A true@w′ at E

There are several reasons to extend IS5 with the at modality. One is that itis a natural and elegant consequence of formalizing IS5 with a world-indexedtruth judgment. Because it directly internalizes the machinery of the proofsystem, it will also give us the ability to make more precise statements. Incontrast, 2 and 3 are “lossy;” consider the following theorem of IS5:

2(A ⊃ B) ⊃ 3A ⊃ 3B

The reading of this proposition is as follows: Given that A implies B in everyworld, and given that A is true in some world, B is true in some world. Thisproposition is true by virtue of the fact that B is true at the same world that Ais true (by using the implication). However, the proposition does not state thatB is true at the same world; in fact, we unable to state such a thing with the 2

and 3 connectives at all. The at modality allows us to make such statements.Once we introduce propositions that quantify over worlds, we can say

2(A ⊃ B) ⊃ ∀ω.(A atω) ⊃ (B atω)

which is stronger than the above. In fact, the 2 and 3 modalities are definablein terms of at and quantification, where 2A is ∀ω.A atω and 3A is ∃ω.A atω.Finally, the precision of the at modality will be necessary in the internals of thecompiler for the purpose of closure conversion (Section 6.4).

Having completed the background discussion of IS5, we are now preparedto use it as the foundation of the ML5 language, which is presented in the nextsection. ML5 will modify the logic in several ways; for comparison, all of thestandard rules are given in Appendix A.

4 The ML5 Language

I have designed and formalized in Twelf a simple calculus based on the modallogic from the previous section. (The calculus appears as the internal languageof the implementation in Section 6.2). This calculus forms the basis of ML5,whose features are toured in this section. However, what is presented hereis only that simple calculus dressed up to make it feel like a programminglanguage; it is not a complete description of the language. The specification

9

of ML5 proper is part of the proposed work. Specifically, I do not cover thefeatures that are treated the same as in SML (e.g. functions, datatypes, tuples).I also treat issues of concrete syntax loosely.

The language ML5 is designed around a Curry-Howard interpretation ofIntuitionistic S5. To do this, we associate proof terms with the rules of thelogic. These proof terms become the syntax of the programming language.

Its main typing judgment is

Γ ` M : A@w

which states that the expression M has type A at the world w, in the context Γ.As in the logic, each assumption in Γ is adorned with the world at which it iswell-typed. Computationally, these worlds are the hosts in the network.

Because every subexpression of the program is typed at some world, anML5 program consists of a tree of nested expressions to be evaluated at differ-ent hosts. Every variable in the context Γ is bound to a value that the programhas access to, and these variables are typed at various different worlds. There-fore the program is able to manipulate both values that make sense to it (onesthat are typed at the same world) and values that do not (ones that are typedat different worlds).

The worlds in the typing judgment are the static representations of hostsin the network. At runtime, we will need tokens with which to refer to theseworlds. A value of type w addr is such a token, which acts as the address of ahost. A host can compute its own address by using the localhost() primitive,which results in an address value of the form w:

Γ ` localhost() : w addr @wlocalhost

Γ ` w : w addr @w′ address

The way an address is used is by switching the location of evaluation to theworld described by the address. This primitive, called get , is ML5’s onlymechanism for moving control and data between hosts.

Γ ` w′ worldΓ ` M : w′ addr@wΓ ` N : A@w′

A mobile

Γ ` get[w′;M ]N : A@wget

The get primitive transfers control from the current world w to the specifiedworld w′. The judgment Γ ` w′ world checks that the world expression w′ iswell-formed (Figure 2). The expression N , which is well-typed at w′, is eval-uated there. The resulting value is then returned to w. For an arbitrary value,this motion is unsound; the value may be, or make use of, a resource that islocal to w′. The final typing condition for get therefore restricts the primitiveto types that are mobile. A mobile type is one whose values are always portablebetween worlds (Figure 1). Primitive types such as integers and strings aremobile. Addresses of worlds are mobile, as are data structures built from other

10

b mobileA mobile B mobile

A×B mobile

2A mobile 3A mobile

α mobile..A mobile

µα.A mobileA mobile B mobile

A + B mobile

w addr mobile

Figure 1: The definition of the mobile judgment. The metavariable b rangesover ML base types like int and string . The rule for recursive types µα.Aintroduces a mobility assumption for the type variable, so mobility is actually ahypothetical judgment. However, no other type variables are ever consideredmobile

Γ, ω world,Γ′ ` ω world Γ ` w world

Figure 2: Definition of the judgment Γ ` w world

mobile types. Abstract types, mutable references, and functions are not mobile,among other things. Some functions and abstract types may still be moved,however, by embedding them in the 2 modality, which is mobile.

Local action. The presence of the get primitive allows us to restrict all otheroperations to dynamically involve only one world. In doing so, we will retainall of the expressive power of the logic.

In the logic, the proposition 3A meant that A is true at some world. Inthe ML5 language, a value of type 3A is an address for some value of typeA, which lives at an arbitrary unknown world. The rules for 3 in ML5 are asfollows:

Γ ` M : A@wΓ ` here M : 3A@w

3 I

Γ ` M : 3A@wΓ, ω world, a:ω addr@w, x:A@ω ` N : C @w

Γ ` letd 〈ω, a, x〉 = M in N : C @w3 E

For both of these primitives, all of the computation happens at the world w.We may only compute the address of the result of evaluating a local expression(3 I). To use something of type 3A, we must have it at the current world (3 E).In the body of the letd , we have in scope a hypothetical world ω where thevalue is, an address a for that world, and the value itself x. In comparison,the rules from Section 3 allowed us to evaluate and take the address of remote

11

expressions, as well as eliminate remote addresses. We can derive those rulesby composing the ML5 rules with get .

In the logic, proposition 2A meant that A is true in every world. In ML5,a value of type 2A is a suspended expression of type A that can be evaluatedanywhere. The rules for the 2 constructor are also purely local:

Γ, ω world ` M : A@ω

Γ ` box ω.M : 2A@w2 I

Γ ` M : 2A@wΓ ` unbox M : A@w

2 E

Although the body of the box is typed at the hypothetical world ω (2 I), thisconstruct does not access any remote worlds at runtime. The code inside thebox is suspended, so box ω.M is already a value. Unboxing is straightforward(2 E); the suspended expression is evaluated at this time. As before, the remoteversion of unbox can be derived by composing this rule with get .

We now have enough to build some small examples, which we will use tomotivate the addition of a new judgment for global reasoning. The followingproposition is one of the characteristic axioms of Intuitionistic S5:

32A ⊃ A

As a type it describes a function that when given the address of some sus-pended portable code of type A we computes a value of type A. In ML5, afunction f of this type is:

fun f (x : 32α) : α =letd <w, a, y> = xin

unbox(get [w;a] y)end

The function f works by getting the portable code from the world indicated bythe address, and then running it locally.

A different characteristic axiom is problematic:

2A ⊃ 22A

In ML5, we might like to write this as follows (supposing we are at the world w):

(* ill-typed *)fun g (x : 2α) : 22α =

let val a : w addr = localhost()in box w’. get[w; a] xend

This code does not type-check. The idea is that we save the address of the localmachine as a. We then create a second box, whose contents is an expressionthat get s the original box from the world w. The reason that this does nottype-check is that the variable a is bound at the world w. The get , which

12

happens at the world w’ but tries to use a, is ill-typed. Moreover, we cannotget the address itself from w, since to do so would require an address for wat w’ , which is the very thing we lack! The solution will be to add a newjudgment to classify values that are well-typed at any world. Addresses willbe such values, which will make the above program well-typed with a smallmodification. The program also has a second problem: the boxed term that wecreate has to contact the home world w every time it is unbox ed. Using thenew judgment we will also be able to create a more efficient implementation ofthis function.

4.1 Validity

To enable global reasoning, we add a new judgment to the language:

Γ ` S ∼ A@w

In this judgment, called the validity judgment, S is a valid expression with typeA at the world w. S will evaluate (at w) to a value that has type A in anyworld. Assumptions of the form u∼A now appear in Γ as well. Since theseassumptions stand for values that are well-typed in any world, they are notannotated with any world at all. A valid hypothesis can be used at any world:

Γ, u∼A,Γ′ ` u : A@wvhyp

Valid expressions take on one of the two following forms:

valid expressions S ::= value ω.v| mobile M

The typing conditions are as follows:

Γ, ω world ` v : A@ω

Γ ` value ω.v ∼ A@wvalue

A mobileΓ ` M : A@w

Γ ` mobile M ∼ A@wmobile

For value , the argument is already a value, which must be well-typed in anyworld. The value is therefore parameterized by a static world ω, and checkedfor well-typedness in that same world. For mobile , the expression must bewell-typed, and the type of the expression must be mobile. This ensures thatafter the expression is evaluated, the result will be well-typed at any world.

The Validity Modality. The valid judgment is internalized to define the cir-cle modality fA. A value of type fA is a suspended expression that, whenevaluated, produces a value that is well typed anywhere [34]. It is defined asfollows:

Γ ` S ∼ A@wΓ ` cir S : fA@w

fI

Γ ` M : fA@wΓ, u∼A ` N : C @w

Γ ` letv u = M in N : C @wfE

13

Because the valid expression is suspended, cir S is a value. At runtime,the letv construct proceeds by evaluating M to the form cir value v orcir mobile M , then evaluating M in the latter form, and then binding the re-sulting value to u for the purpose of evaluating N .

The fmodality allows us to type the above attempt at implementing 2A ⊃22A:

fun g (x : 2α) : 22α =letv u ∼ w addr = cir (mobile (localhost()))in

box w’. get[w; u] xend

In this version, we are able to use the address for w at the world w′ because it isa global hypothesis. A shortcoming remains: the box produced in this versionmust contact the world w every time it is unboxed. An improved version usesthe fact that 2α is mobile to create a valid hypothesis v from the argument x ,which can then be used directly at w′:

fun g (x : 2α) : 22α =letv v ∼ 2α = cir (mobile x)in

box w’. vend

The type fA is not mobile, because the suspended expression of type Ais typed with respect to the world where the circle is introduced. A portablesuspended expression that produces a portable value would have type 2 fA.

A common idiom is to introduce the circle modality and then immediatelyeliminate it in order to bind a valid variable. ML5 therefore provides two de-rived forms:

putv u ω = v in N.= letv u = cir(value ω.v) in N

putm u = M in N.= letv u = cir(mobile M) in N

Polymorphism. Like Standard ML, ML5 supports prenex parametric poly-morphism over types. It also supports polymorphism over worlds in an anal-ogous way. We create a new syntactic class of polytypes, and two new formsof hypothesis that can appear in Γ:

polytypes P ::= ∀α1, . . . , αn, ω1, . . . , ωm.Acontexts Γ ::= . . . | x:P @w | x∼P

Only assumptions can have polymorphic type. Every use of a polymorphicassumption must completely instantiate the polymorphic type:

Γ, x:(∀α1, . . . , αn, ω1, . . . , ωm.A)@w,Γ′ `x〈A1, . . . , An,w1, . . . ,wm〉 : ([ A1/α1 , . . . ,

An/αn, w1/ω1 , . . . ,

wm/ωm]A)@w

polyhyp

14

Polymorphic variables are introduced by additional polymorphic versionsof the val , fun , and letv bindings. For instance, the additional val rule is asfollows:

Γ, α1 type, . . . , αn type, ω1 world, . . . , ωm world ` v : A@wΓ, x:(∀α1, . . . , αn, ω1, . . . , ωm.A)@w ` N : C @w

Γ ` let 〈α1, . . . , αn;ω1, . . . , ωm〉 val x = v in N : C @wval

ML5 has a value restriction, like SML: A binding can only be polymorphic ifthe right hand side is a value. This allows the type inference process to insertquantifiers without changing the dynamic meaning of the program. This pro-posal does not include a description of type inference, but I expect it to be astraightforward extension of the standard algorithm.

The at Modality. A value of type A atw is an encapsulated value, where thatvalue is well-typed at another world.

Γ ` v : A@w′

Γ ` holdw′ v : A atw′@wat I

Γ ` M : A atw′@wΓ, x:A@w′ ` N : C @w

Γ ` leta x = M in N : C @wat E

The leta binding consumes a value of type A atw′ by putting an assumptionx:A@w′ in the context. The value holdw′v represents the encapsulation of v.Its body must be a value because we are not in general at the correct world toevaluate it; consider the following ill-formed code:

(* ill-typed *)let val x = hold[w’] (ref 0)in leta y = x

inM

endend

If this code is to be allowed, then within the expression M , y should be boundto an allocated reference at w’ . There has been no opportunity to create sucha reference, however. The static world w’ might not even have a dynamicaddress available at this point, which would be necessary to make contact withit.

Dynamically, hold is just a type coercion and leta behaves just like let .

Sums. Sum types, which come from the disjunctive connective in logic, arenot entirely straightforward. Like the elimination form for 3, the standardlogical rule for disjunction allows the remote elimination of A ∨B:

Γ ` A ∨B true@w′

Γ, A true@w′ ` C true@wΓ, B true@w′ ` C true@w

Γ ` C true@w∨ E

15

In this rule A ∨B may be at a different world (w′) than our current one (w). Sofar, all rules in ML5 other than get have acted solely on local data. We wouldlike to maintain this, so that (for one thing) existing single-world ML code stillruns without any overhead from the distributed features. The local rules forsum types in ML5 are:

Γ ` M : A + B @wΓ, x:A@w ` N1 : C @wΓ, x:B @w ` N2 : C @w

Γ `case M of

inl x ⇒ N1

| inr x ⇒ N2

: C @w

+ E

Γ ` M : A@wΓ ` inl M : A + B @w

+ I1Γ ` M : B @w

Γ ` inr M : A + B @w+ I2

For 2 and 3, the get construct makes the nonlocal logical rules derivable.This does not work as easily for disjunction, because we cannot get a value ofarbitrary sum type (A∨B is only mobile if both A and B are mobile.) However,the nonlocal case analysis is still derivable in ML5. Here is one way to do it; therule

Γ ` O : w′ addr @wΓ ` M : A + B @w′

Γ, x:A@w′ ` N1 : C @wΓ, x:B @w′ ` N2 : C @w

Γ `case[w′;O] M of

inl x ⇒ N1

| inr x ⇒ N2

: C @w

+ E-nonlocal

can be implemented as

letval mr = get[w’; O]

(case M ofinl y => inl (hold[w’] y)

| inr y => inr (hold[w’] y))in

case mr ofinl x’ => leta x = x’

in N1end

| inr x’ => leta x = x’in N2end

end

Here, the type of value that we get is A atω′ + B atω′, which is guaranteedto be mobile. Therefore, we retain all of the strength of the logical ∨ connective

16

in IS5. The only downside is that this derivation requires us to enlist the atmodality. The consequence is that the logical completeness relies on the pres-ence of both ∨ and at, meaning that the two are not truly orthogonal in thelanguage.

Like in Standard ML, labeled sums will actually be supported (along withrecursive types) as part of the datatype mechanism.

Properties. The language presented here should have two main properties.First is type safety: Every well-typed program can take a step to another well-typed program, or is already a value. I have proved type safety in Twelf fora simplified but representative version of the calculus. Second is a connectionto the logic: the modifications that we have made (particularly the use of getand locally-acting rules) should not have reduced the expressive power of thelanguage. We prove for two related lambda calculi [31, 30] that this alternateformulation proves exactly the same theorems as the standard presentation ofthe logic. Both of these proofs have also been formalized in Twelf. Part of thethesis research will be extending this result to the pure subset of ML5 (withthe fand at modalities) as well.

5 Code Examples

The following small examples illustrate how the constructs of ML5 can be usedto build distributed applications.

Mobile code proxy. Many distributed programming languages provide away of forming “proxies” for code that cannot itself move. These proxies canthen be passed around, and used as stand-ins for the functions they mimic.In ML5, if the argument and return types of a function are mobile, then onecan create a proxy for it. Here we’ll assume we have a variable f :A → B @w0

and will bind a valid variable u∼A → B which is the mobile proxy for thatfunction. This assumes that A and B are mobile.

putm w0a = localhost()in putv u w’ =

(fn a =>putm v = ain

get [w0; w0a] (f v)end)

in...

endend

We begin by computing the address of w0 and making it valid, so that wecan contact w0 from any world. We then bind u to a function value, which is

17

the proxy. The proxy works by taking the argument (known to be mobile byassumption) and making it valid as well. The proxy then performs a get toapply the original function at w0 and return the result.

Cords. Assuming some simple facilities for concurrency and the discovery ofidle hosts, we can also emulate the features of Grid/ML in a statically-typedway. The Grid/ML client will be world h, which is the world that the programbegins running on in ML5. Let’s suppose that the following are bound in thecontext:

future::Type → Type,future ∼ ((unit→ α) → α future),now ∼ (α future→ α),

find idle ∼ (unit→ 3unit)

We assume Multilisp-like futures, which are a simple mechanism for fork-joinparallelism. An α future is a computation, running concurrently, that pro-duces a value of type α when synchronized on with now. Futures must allowthe execution of arbitrary ML5 code, but needn’t have any special features fordistribution. We also expect a find idle routine to give the address of anidle host, which is represented here as 3unit. All of these primitives are validhypotheses, so they can be used in any world.

With this, we can implement a “mobile spawn” function like the one that isprovided by Grid/ML.

(* spawn ∼ ∀α, ω.( 2( α at ω) -> ( α at ω) future) *)putv 〈α, ω〉 spawn w2 =

(fn (code : 2( α at ω)) =>future (fn () =>

letd <w3, w3a, ()> = find_idle()in putm c = code

in get[w3; w3a] (unbox c)end

end))in

...end

This implementation of spawn takes as an argument a piece of suspended codesuitable to run at any world. That suspended code must produce a result thatis well-typed at the world ω. The function spawn is polymorphic in ω, so thisis the caller’s choice. It then produces a future that finds an idle host and runsthe code there.

The following code shows how spawn could be used from the homeworld h:

val f = spawn 〈h, int 〉(box _,_.

18

let fun nfactors (n : int) : int = ...in putm res = nfactors n

in hold[h] resend

end)

(* ... some computations in parallel ... *)val answer : int = (leta a = now f in a end)

This program invokes spawn with some “cord” code. That cord computes thenumber of factors of some specific n , and coerces the resulting value (an inte-ger, which is mobile) to the world h. There is no requirement that the resultof the computation be mobile; if we like, it can be specifically tailored to theworld that spawns it. Once we’ve spawned the cord f , we can later wait on itsanswer with now. Since it has type int at h and we are running at h, we canuse leta to unencapsulate the result into a regular integer.

Although this requires more text than using the built-in primitives ofGrid/ML, ML5 has the advantage of superior static checking. The type sys-tem ensures that the code given to spawn can run anywhere, and ensures thatthe result is well-formed at the world h. Unlike Grid/ML, we can also be morespecific about the capabilities of the hosts on which our mobile code will run.Here we have represented the addresses of hosts as 3unit. If we wanted toexpress the idea that machines on the Grid have their own distinct set of ca-pabilities, we need only amend the implementation of find idle to return3 caps for some appropriate description of its local capabilities.

Having toured the language’s features and looked at some simple exam-ples, we now switch gears to a discussion of its implementation.

6 The ML5 Compiler

This section describes the planned implementation of a compiler for ML5. Theearly phases of the compiler have been studied in detail. The later phases havenot; part of the thesis work will be to figure out the best course of action forthese and take it.

6.1 Design Issues

Before walking through the phases of the compiler, it is important to recallsome of the issues that will guide the design.

Data Representation. The chief thing that makes the implementation of ML5different from a standard type-directed compiler for ML is that programs areable to manipulate data that are typed at different worlds. Because of our local-only elimination rules, the only way that these data can be used is in prepara-tion of code or data also intended to be evaluated at other worlds. Therefore,

19

the implementation has considerable flexibility in the way these abstract re-mote values are represented—the choices can be guided almost entirely by themarshalling strategy.

Marshalling. Because ML5 programs run on a network, we require the abilityto marshal code and data into raw bytes to be sent over that network. Thecompiler will support the runtime in this task by providing marshalling andunmarshalling functions for each abstract type. (Recall that any ML5 value canbe marshalled, even if the type is not mobile.)

Certification. In order to use ML5 in our trustless Grid computing project,the compiler must produce certificates that demonstrate the safety of the mo-bile code. I will do this by building a type-directed compiler that preservesand translates types throughout the phases of compilation. The compiler willoutput typed assembly code for the TALT system [13].

The phases of compilation are as follows. First, the external language (ML5)is elaborated into a simpler internal language (IL) (Section 6.2). Second, weconvert this IL to continuation passing style (CPS) (Section 6.3). Next, we per-form closure conversion to implement lexically scoped closures with closedfunctions (Section 6.4). Each of these phases is standard [28] apart from thenew features of ML5, so the description concentrates on those.

6.2 Elaboration

The purpose of elaboration is to replace features of convenience in ML5 withthe simpler type theoretic constructs of the IL. For the purpose of this proposal,those features are the 2 and 3 modalities and world polymorphism.

World Quantification. In the IL, type inference is no longer an issue. Wecan therefore abandon ML5’s restriction to prenex polymorphism, which wasexpressed in terms of a syntactic class of “polytypes.” Instead we simply havethe type constructor ∀ω.A:

Γ, ω world ` v : A@wΓ ` Λω.v : ∀ω.A@w

∀ IΓ ` M : ∀ω.A@w

Γ ` M〈w′〉 : [w′/ω]A@w∀ E

The IL supports a “type-erasure semantics” [28] where types are purely staticentities, and the term constructors that manipulate them can be erased withoutchanging the dynamic meaning of the program. To achieve this, the constructorΛ is restricted to values. This is all we need for the elaboration of ML5, wherepolymorphism is also restricted to values.

The IL also has a first-class existential quantifier, which will be used for

20

closure conversion and the elaboration of 3:

Γ ` w′ worldΓ ` v : [w′/ω]A@w

Γ ` pack[w′]v as ∃ω.A : ∃ω.A@w∃ I

Γ ` M : ∃ω.A@wΓ, ω world, x:A ` N : C @w

Γ ` unpack M as ω, x in N : C @w∃ E

The Elaboration Relation. Elaboration is given as a function on ML5 typ-ing derivations. As a shorthand, we write this as a function on expressions,[[·]]A@w

E , parameterized by the current world w and the type A of the expressionbeing translated.2 We also give a function that translates ML5 types [[·]]E. Forthe syntactic classes of values and valid expressions, we have have two addi-tional translations [[·]]A@w

VE and [[·]]A@wSE . The cases for eliminating the 2 and 3

modalities are:

[[2A]]E = ∀ω.((unit→ [[A]]E) atω)[[3A]]E = ∃ω.([[A]]E atω × ω addr)

[[box ω′.M ]]2A@wVE = Λω′.holdω′λ().[[M ]]A@ω′

E

[[unbox M ]]A@wE = leta x = [[M ]]2A@w

E 〈w〉 in x() end

[[here M ]]3A@wE = let x = [[M ]]A@w

E inlet a = localhost() inpack[w](x, a) as ∃ω.([[A]]E atω × ω addr)

[[letd 〈ω, a, x〉 = M in N ]]C @wE = unpack [[M ]]3 @w

E as ω, y inlet x = fst y inlet a = snd y in [[N ]]C @w

E

World polymorphism in ML5 is translated into uses of the ∀ω quantifier inthe IL. Because polymorphic types are a different syntactic class in ML5, thisrequires another translation [[·]]∀E for polytypes.

[[∀α1, . . . , αn, ω1, . . . , ωm.A]]∀E = ∀α1. . . . ,∀αn.∀ω1, . . . ,∀ωm.[[A]]E

[[x〈A1, . . . , An,w1, . . . ,wm〉]]A@wE = x〈A1〉 . . . 〈An〉〈w1〉 . . . 〈wm〉

[[let val 〈α1, . . . , αn, ω1, . . . , ωn〉x = v in N ]]C @wE

= let val x = Λα1. . . . Λαn.Λω1. . . . Λωm.[[v]] @wE

in [[N ]]C @wE

Type Polymorphism. One final phase is needed to eliminate the need fortypes at run-time. The program must be able to marshal values of any type,including the abstract type variables bound by Λ. I will achieve this by usingdictionary-passing to make available a marshalling and unmarshalling func-tion for each type variable. This is a standard implementation technique fortype classes [48]. Section 6.5 explains marshalling in more detail.

2In some recursive invocations of the function, we must produce with the type of a subexpres-sion, where that type is not evident from the expression itself. This is why elaboration workson typing derivations (where all of the types of subterms are present) rather than directly on theexpressions. In those recursive calls we write for the missing type.

21

Properties. Elaboration should be type-preserving in the following sense,where [[Γ]]E is the natural extension of [[A]]E to contexts:

Property 1 (Type soundness of elaboration)(a) If Γ ` M : A@w (in the EL)

then [[Γ]]E ` [[M ]]A@wE : [[A]]E @w (in the IL).

(b) If Γ ` v : A@w (in the EL)then [[Γ]]E ` [[v]]A@w

VE : [[A]]E @w (in the IL).(c) If Γ ` S ∼ A@w (in the EL)

then [[Γ]]E ` [[S]]A@wSE : [[A]]E @w (in the IL).

This property has been formalized and proved in Twelf for a simplifiedexternal language without polymorphism [25]. 2

6.3 Continuation Passing Style

After elaborating into the IL, the goal of the compiler is to repeatedly simplifythe code by removing the use of constructs that have no direct analogue inmachine code. The first such translation serializes the evaluation of expressionsand makes control flow explicit by putting the program in continuation passingstyle [4].

Other than the translation of valid expressions and get , CPS conversion isstandard. Figure 3 contains a representative sample of the CPS language (thedynamic semantics for this fragment are given in Appendix C). A value of typeA cont is a continuation expecting a value of type A. Its canonical form is λx.c.The type aA is a new modality that is used to compile the fA modality. Avalue of type aA is an encapsulated value that is well-typed anywhere. It is aninternalization of the u∼A hypothesis just as the at modality is an internaliza-tion of the x:A@w hypothesis. The canonical form of type aA is cval ω.v. Thevalue w represents an address for the world w. Such values are introduced bythe localhost operation.

We use the judgmentΓ ` c@w

to type-check CPS expressions, because they do not return (and so they cannotbe distinguished by return type). We use

Γ ` v : A@w

22

exps c ::= leta x = v in c| letgu = v in c| liftu = v in c| let x = fst v in c| let x = snd v in c| let x = mkpair v1, v2 in c| let x = localhost() in c| . . .| go[w; va] c| call vf (vx)| halt

values v ::= 〈v1, v2〉| holdwv| λx.c| Λω.v| Λα.v| cval ω.v| w| u| x| . . .

types A,B ::= A cont | A×B | A atw| aA | ∀ω.A | ∃ω.A| w addr | . . .

Figure 3: A representative sample of the CPS language

23

[[A → B]]C = ([[A]]C × ([[B]]C cont)) cont[[ fA]]C = (a[[A]]C) cont cont

Figure 4: Selected cases for the CPS type translation

b cmobileA cmobile B cmobile

A×B cmobile

α cmobile..A cmobile

µα.A cmobileA cmobile B cmobile

A + B cmobile

A cmobile∀α.A cmobile

A cmobile∀ω.A cmobile

A cmobile∃α.A cmobile

A cmobile∃ω.A cmobile

w addr cmobile

Figure 5: The definition of the cmobile judgment

to type-check values. The interesting typing rules are as follows:

Γ ` va : w′ addr@w Γ ` c@w′

Γ ` go[w′; va] c@wgo

Γ ` vf : A cont @w Γ ` vx : A@wΓ ` call vf (vx)@w

cont E

A cmobileΓ ` v : A@wΓ, u∼A ` c@w

Γ ` lift u = v in c@wlift

Γ, ω world ` v : A@ω

Γ ` cval ω.v : aA@wa I

Γ ` v : aA@w Γ, u∼A ` c@wΓ ` letg u = v in c@w

a E

In the CPS language, go replaces ML5’s get . The go construct invokes a con-tinuation at a remote world. In contrast to the IL’s get , go is not restricted tomobile types, because it is only a control-flow construct. The mobility restric-tion shows up in lift, which is also used in the translation of get below.

The call primitive is used to pass a value to a continuation. It simply re-

24

quires that the argument is the same type that the continuation expects, andthat both are typed at the same world. The lift construct binds a valid vari-able to a value whose type is cmobile. The cmobile judgment is analogous tothe mobile judgment from ML5 and its definition appears in Figure 5. The cvalconstruct, which is the introduction form for the a modality, requires a value.The typing rule checks that the value is well-typed in any world by checkingit in a fresh hypothetical world. The elimination form, letg, simply binds thevalid variable in the continuation.

There are four translations to convert from the IL to CPS, which translate ILtypes, expressions, values, and valid expressions. The translation of IL typesto CPS types is given by a function [[·]]C. The interesting cases are given inFigure 4. An important lemma states that this translation preserves our notionof mobility:

Lemma 1 (Preservation of Mobility)If A mobile then [[A]]C cmobile.

Proof is straightforward by induction on the derivation of A mobile. 2

The translation of IL terms to CPS terms is given in terms of a higher-orderfunction convert. It takes as arguments the current world, an IL expression, anda meta-level continuation to which the result of converting the IL expression ispassed. For example, the translation for tuple construction is as follows:

convert w 〈M1,M2〉 K =convert w M1 K1

where K1(v1) =convert w M2 K2

where K2(v2) =let x = mkpair v1, v2

in K(x)

The translation of IL values is given by a second function, [[·]]wCV, which producesa CPS value. This is standard; we give only a few cases:

[[n]]wCV = n[[λx.M ]]wCV = λy.let x = fst y in

let k = snd y inconvert w M K

where K v = call k(v)...

[[cir S]]wCV = [[S]]wCS

The case for cir makes use of the third translation function, [[·]]wCS. It takes avalid expression of type A and the current world, and produces a CPS value of

25

type (a[[A]]C) cont cont. This function is defined as follows:

[[valid ω.v]]wCS = λk.call k(cval ω.v)[[mobile M ]]wCS = λk.convert w M K

where K(v) =lift u = v incall k(cval ω.u)

We can now give the interesting cases of convert. The elimination formfor fis translated into a use of letg:

convert w (letv u = M in N) K =convert w M K1

where K1(v) = call v(λx. letg u = x inconvert w N K)

The result of converting M (of type fA) is a value of type (a[[A]]C) cont cont.We call this continuation with a continuation that unpacks its argument into avalidity variable and proceeds with the translated body of the letv .

The other interesting case is the translation of get :

convert w (get[w′;Ma]Mr) K =convert w Ma K1

where K1(va′) =let a = localhost inlift ua = a ingo[w′; va′ ] convert N w′ Kr

where Kr(vr) =lift ur = vr ingo[w;ua] K(ur)

The translation consists of two uses of go ; one to transfer control to the remoteworld, and one to come back. We start by evaluating Ma to the value va′ , theaddress for the remote world. We then compute the local address a, whichwill be used to get back. Because we need to use this address from the remoteworld, we create a valid hypothesis ua from it with lift (addresses are mo-bile). We then transfer control to the world w′ with go . While in the worldw′, the translation of N is evaluated. Since we want to use the result vr backat the original world w, it is made into a valid hypothesis using lift again.The typing condition for the IL get construct requires A to be mobile, so byLemma 1 the type of this value is cmobile as required. The code then returnsto the world w to continue with the final result.

Properties. The CPS translation should satisfy the following properties,where [[Γ]]C is the natural extension of [[A]]C to contexts:

26

Property 2 (Type soundness of CPS translation)(a) If Γ ` v : A@w (in the IL)

then [[Γ]]C ` [[v]]wCV : [[A]]C @w (in CPS).(b) If Γ ` S : A@w (in the IL)

then [[Γ]]C ` [[S]]wCS : (a[[A]]C) cont cont @w (in CPS).(c) If Γ ` M : A@w (in the IL)

and for all v such that [[Γ]]C ` v : [[A]]C @w, [[Γ]]C ` K(v)@w (in CPS)then [[Γ]]C ` (convert w M K)@w (in CPS).

This property has been proven and formalized in Twelf for a similar lan-guage without the validity judgment, f, and a modalities [25]. 2

6.4 Closure Conversion

The next important step in compilation is closure conversion. Although low-level machine languages have the ability to represent higher-order code (bypassing addresses of code), there is no direct support for nesting these codeblocks within one another with lexical scope. Closure conversion implementslexical scope by constructing an explicit environment for each λ, so that eachfunction is actually closed.

Once every function is closed, we can hoist the definitions to the top level,and refer to them by label rather than variable. In our distributed setting, theidea is that each label globally identifies a code block, so that we need only topass around labels and environments in order to implement mobile code. Todo this, every host must have the code for every label that it might be asked toexecute; one conservative approximation simply gives every host access to allcode in the program.

Closure conversion in this setting is conceptually standard, but is compli-cated by the presence of valid hypotheses and hypotheses at worlds other thanthe current world. For instance, the following (IL) function at world w0 has afree variable at w1:

a:w1 addr@w0, x:int @w1 ` λy.y + get[w1; a]x : int→ int@w0

To generate an environment for this function, we need to reify the remote hy-pothesis as a value. Because it does not make sense here, we do this by usingthe at modality.

The destination language of closure conversion is the same as for CPS, ex-cept for the typing rule for the go construct. For the sake of economy, we reusethe CPS language and add a new construct go cc which we use in place of theold.

The closure conversion algorithm is given by three functions. One convertsCPS types to CPS types. The only types that are affected by the translation arefunction (continuation) types. The type of a converted continuation will be anexistential:

[[A cont]]CC = ∃αenv.αenv × (([[A]]CC × αenv) cont)

27

The other two functions translate CPS expressions and values, respectively. Forthe translation of values, only lambdas are affected:3

[[λx.c]]CC = pack 〈Benv, 〈venv, λp.c′〉〉as ∃αenv.αenv × (([[A]]CC × αenv) cont)

where. . .c′ = let x = π2 p in

let e = π1 p inleta FV(c)1 = π1e in

...leta FV(c)n = πne inletgFSV(c)1 = πn+1e in

...letgFSV(c)m = πn+me in[[c]]CC

venv = 〈holdFVW(c)1(FV(c)1), . . . , holdFVW(c)n(FV(c)n),

cval ω′.(FSV(c)1), . . . , cval ω′.(FSV(c)m)〉Benv = [[FVT(c)1]]CC atFVW(c)1 × . . .× [[FVT(c)n]]CC atFVW(c)n×

a(FSVT(c)1)× . . .× a(FSVT(c)m)

n = Number of free regular variables in c.FV(c)i = The ith free regular variable of c.

FVT(c)i = The type of the ith free regular variable of c.FVW(c)i = The world of the ith free regular variable of c.

m = Number of free valid variables in c.FSV(c)i = The ith free valid variable of c.

FSVT(c)i = The type of the ith free valid variable of c.

Note that the translation of λx.c, a value, is also a value. Because we havelasting restrictions on the bodies of e.g. hold, it is important to preserve thesyntactic classes of values and expressions in these translations.

The translation of expressions only affects call and go :

[[call vf (vx)]]CC = unpack [[vf ]]CC as 〈αenv, p〉 inlet f = fst p inlet e = snd p inlet a = mkpair[[vx]]CC, e incall f(a)

[[go[w; va]c]]CC = go cc[w, [[va]]CC][[λ .c]]CC

The translation of call is a standard closure call. We unpack the closure, buildthe argument to the function (which consists of the original argument alongwith the function’s environment) and call it. The translation of go is necessary

3Here we assume the language has n-ary products with projections πi.

28

in order to explicitly represent the continuation as a closure, which is what istransmitted over the network in the implementation. The typing rule for go ccis:

Γ ` va : w′ addr@w Γ ` vk : ∃αenv.αenv × ((〈〉 × αenv) cont)@w′

Γ ` go cc[w′; va] vk @wgo cc

Properties. Closure conversion should admit the following properties:

Property 3 (Soundness of closure conversion)(a) If Γ ` v : A@w (in CPS)

then [[Γ]]CC ` [[v]]CC : [[A]]CC @w (in CPS).(b) If Γ ` c@w (in CPS)

then [[Γ]]CC ` [[c]]CC @w (in CPS).(c) If Γ ` v : A@w (in CPS)

then for every subterm v′ of the form λx.c within [[v′]]CC,FV(v′) = FSV(v′) = ∅.

(d) If Γ ` c@w (in CPS)then for every subterm v of the form λx.c′ within [[c]]CC,FV(v) = FSV(v) = ∅.

Because of the relative difficulty of formalizing context operations like FVin Twelf, this proof has only been done on paper. Like Property 2, the proofwas done for a similar language without a validity judgment or a modality.

6.5 Backend

The backend of the compiler transforms the low-level compiled program intotyped assembly language that can be executed by the machine. For the ML5compiler, I will target the TALT system in active development by Crary et al. atCarnegie Mellon [13].

I have not yet designed the backend. Vanderwaart’s resource-boundedPopcorn compiler [44] has a code generator that produces TALT code from alow-level typed intermediate language. I plan to try to reuse this code with mi-nor modifications. Even if this turns out to be impossible, generation of typedassembly language is a solved problem; there are only a few new challenges inthis setting:

Marshalling. ML5 programs must be able to marshal arbitrary code and datainto raw bytes for transmission on the network. By using a dictionary-passingscheme [48] we can arrange for marshalling and unmarshalling functions tobe available whenever they are needed. Writing these marshalling functionsin a type-safe way will take special care, but the problem has been studiedbefore [15, 14].

29

Binding to Local Resources. More interesting will be the problem of iden-tifying and binding to local resources. One of the primary motivations ofthe work is the controlled access to local resources (for example, a valuelineprinter : string → unit@w8108). During unmarshalling, code thatmakes use of a local resource must have these open references bound to thoselocal resources. The problem is slightly different from marshalling, becausein general, the host that prepares the marshalled code can only name thoseresources—it cannot make sense of them in the same way it can make sense ofcommon data like tuples and portable code.

I solved a very similar problem in the Hemlock compiler with an easy adhoc solution. Generalizing that technique to this case would mean providing auniform table on each host with one entry for every local resource that is usedin the program. The table is initialized by the runtime. On the host where theresource is present, the table entry contains a tagged reference to the resource,and accesses to it succeed. Accesses to non-existent resources fail with a run-time error. Although this scheme would work for the ML5 implementationas well, it is worth investigating how to avoid this run-time check. However,note that even if the implementation incurs the cost of a run-time check, thetype system guarantees that such a check will never fail.

Allocation and Valuability. Allocation conversion [28] is a pass that makesthe allocation and initialization of memory explicit. The standard way of allo-cating the tuple 〈830, 1〉, for example, is to generate code such as the following:4

let x = malloc(8, int * int)let _ = x[0] := 830let _ = x[1] := 1

Several constructs in the internal language, such as hold and cval, have a syn-tactic restriction to values that is necessary for safety. Many values, however,require allocation. This makes those values into effectful expressions, such thatthose programs can no longer be typed in our language! One solution is to re-lax the value restriction to one of valuability. A “valuable” expression may haveeffects, but it can safely be evaluated by one world on behalf of another. I haveonly sketched such a system on paper.

By postponing allocation conversion until after translation into a languagelike TALT that is not modally typed, we can sidestep this issue completely. Still,it is interesting to figure out what the right thing to do in this case is, even if Ido not actually implement it.

7 The ML5 Runtime

Related to the backend of the compiler is the language runtime. The runtime isthe software that enables a compiled program to run by mediating between it

4The actual code would be more complicated, mostly due to type systems for initialization, butthat is not at issue here.

30

and the environment. In the case of a distributed programming language, thisincludes forming and maintaining the network on which the program runs.

The ML5 runtime will be similar to the ConCert Conductor [29], and I ex-pect to be able to reuse much of the network code developed for that software.In many ways it will be simpler, because it does not need to support featureslike automatic failure recovery and peer-to-peer node discovery. However,there are again some special concerns for ML5:

Concurrency. A logical account of concurrency is firmly outside the scopeof this thesis. However, some minimal support for concurrency will likely benecessary to develop a compelling distributed application. A simple fork/joinmechanism like futures (as used in Section 5) may suffice. Typed CML-stylechannels [38] might be easily implementable using the same marshalling mech-anisms already planned.

Any of these should integrate cleanly with the spatial distribution featuresof ML5, the implementation burden being the main cost. The demands of theapplication should dictate which features I include.

Garbage Collection. In order to support long-running programs, the runtimemust reclaim abandoned storage. The TALT runtime already includes a con-servative garbage collector for locally allocated data. However, as referencesto local data spread (in the environments of mobile code) to other places in thenetwork, we cannot safely reclaim these data without ensuring that all globalreferences have been discarded. Distributed garbage collection is a problemthat has been studied, but the solutions are quite complicated [37]. At a mini-mum, it may be feasible to simply never reclaim data that may have non-localreferences. If not, then the most complicated scheme I would attempt wouldbe very naıve, stopping the entire world in order to conduct a scan for datawith no global references.

8 Application

I plan to demonstrate the effectiveness of ML5 and its implementation by build-ing an example distributed application. The application will be chosen to showoff the features that I have time to implement, so I have not committed to aspecific application yet. Optimally, the application I choose would have thefollowing characteristics. Most of its complexity should come from the wayit is distributed, not from the particular computations it does at each host. Itshould manage location-dependent resources and effects in a non-trivial way,and should make use of the higher-order programming techniques enabled byML5’s type system. Finally, a similar application should have an implementa-tion in at least one related system, so that the two can be compared.

31

9 Related Work

Distributed computing is a huge area of computer science, suggesting a largebody of related work. Most of this work is only superficially relevant to thisproposal, and the relationship can be summarized in terms of a few majorthemes. A few more closely related languages are described in detail below.

A Language, not a Tool. ML5 is an abstract language designed for spatiallydistributed computing on a foundation of logic. In contrast, many systemsused for distributed computing are ad hoc extensions of existing languages. Inmany languages used in industry, the mechanisms for distributed computingare provided in the form of libraries and stub generators (e.g. CORBA [50, 45],DCOM [7], .Net [33], Web Services [47, 46]).

By building ML5 from first principles, and by using the Curry-Howard Iso-morphism to guide its design, we are able to isolate key concepts of spatialdistribution and codify them in a natural way within the type system. Theresult is a language that is more elegant.

Marshalling and Data Mobility. A common shortcoming of distributed lan-guages and tools is that they place restrictions on the types of data that canbe marshalled and sent to other hosts. CORBA, whose basic primitive for dis-tributed programming is the remote procedure call, limits the types of RPCarguments to a few simple base types. In Java RMI [16], objects matching theSerializable interface can be marshalled, but this does not include refer-ences to local resources such as file handles. I contend that this restriction stemsfrom a mistaken conflation of two separate notions. First is the implementationtechnique of marshalling, which is simply a way of representing a piece of datain a format suitable for transmission on a network. The second is the potentialmobility of data, that is, the fact that some data make sense at more than oneworld. In most languages these ideas are conflated because distributed appli-cations essentially consist of a collection of separate programs, each of whichcan only understand data from its own perspective. When a Java program per-forms a remote procedure call, the function that is called can’t help but requirethat all its arguments make sense to it, because the only notion of “makingsense” is one of “making sense locally.” Therefore, every remote procedurecall requires that the arguments shift from making sense to the caller to mak-ing sense at the receiver. Because this shift always occurs at the same time asmarshalling, they seem like the same operation.

The modal type system of ML5 makes the distinction easy to see, becauseit endows programs with the ability to simultaneously reason about the well-formedness of values from multiple perspectives. An ML5 program may ob-serve that a value it holds also makes sense at another world, and therefore cancoerce it to a value well-typed at that world. If it then performs a remote pro-cedure call, it may pass along that value, knowing it makes sense in the calledprocedure’s world. A program can also pass along a value that only makes

32

sense to it—in which case the called procedure knows that the value it has re-ceived is only well-typed at the caller’s world. In either case, marshalling issimply an implementation technique; any value can be marshalled for trans-mission, even if it does not make sense on one end of the transaction. Thispermits more flexibility in the way programs are written, particularly whenprogramming with higher-order functions.

The Location of Effects. Another feature of ML5’s modal typing discipline isthat it is able to directly control access to local resources in a statically checkedway. I believe that no other distributed programming language features thisability. For instance, in Java RMI almost all checks happen dynamically, whichmeans that more bugs can survive until run-time. These run-time checks in-clude the dynamic serializability of arguments or return types of methods thatare invoked remotely, as well as any checks that the Java program must maketo ensure that local resources are present when it needs them. For an exampleof the latter: when implementing a client/server database system, it is possiblefor the client to instantiate a local instance of the server object

Server serv = new Server();

instead of getting a remote instance via RMI

Server serv =(Server)Naming.lookup("rmi://server.org/dbserv");

Unless special precautions are taken, this compiles and works until the servercode attempts to find the local database on the client computer, which fails.Similarly, the client can call any public helper code or methods on objectsthat are intended for use only by the server. If the programmer wishes to ex-clude such erroneous programs, it is often possible to use Java mechanismslike private fields and inner classes to control access to location-dependentresources. To do so, one must identify the concept of location with the conceptof class membership (the only notion of principal in the language). In contrast,ML5 provides a type structure that allows the programmer to directly expressthese location dependencies. I claim that this is exactly the relevant concept forspatially distributed programs.

9.1 Distributed ML-Like Languages

Several lines of research have extended ML-like languages with explicit sup-port for distributed computing. Some present a very different abstraction ofthe network; for instance, D’Caml’s model [49] is a single parallel computerwith a unified store. This model solves the problem of controlling access to lo-calized resources by making every resource available everywhere through theautomatic creation of proxies. This has the disadvantage of obscuring the per-formance characteristics of the code, because any read, write, or even copy of amemory location can require a request over the network. ML5 is lower level in

33

that it attempts to describe the spatial distribution of data with a type structurerather than abstract away from it.

Acute. Acute [41] is a new ML-like language for distributed computing. Themodel it supports is more difficult than ours: a dynamic linking setting whereinteracting programs across hosts may be upgraded to different versions whilethe program is running. The general mechanism in Acute for controlling lo-cality is its dynamic rebinding system. This allows the programmer to marklibraries so that references to them are rebound to local versions when code ar-rives at a site. In ML5, every variable or label refers to a single binding site, be itbound in the program or in the initial context that describes the local resourcesin the network. This improves the programmer’s ability to reason staticallyabout programs. On the other hand, dynamic binding is a reality of manydistributed applications. It may be possible to explicitly implement dynamicbinding on top of ML5’s static type system, which would be interesting futurework.

Like several other languages in this category, Acute allows for the mar-shalling of arbitrary values, and because of the dynamic framework must takespecial care to preserve abstraction between distributed modules and moduleversions. In comparison, because we check the entire program during a singlestatic link, we are able to treat abstraction as a high-level issue that is simplynot present when running machine code.

Alice. Alice [39, 1] is a project to build a new SML-like language with manyadditional features, including distribution. In Alice, marshalling is called pick-ling, and the story is similar to Java: Stateful values such as arrays are freshlycopied, and pickling fails at runtime for “sited” values (those that contain site-specific resources like file handles or thread IDs). As in Java, sitedness is notevident from the type of a value. Hosts have the ability to publish picklablevalues for receipt by other hosts, and to spawn new threads of control. Asusual, there is no typing support of the kind we offer, in fact, “you must becareful not to use sited values in a service!” [2] or run-time errors may occur.

9.2 Modal Logic in Distributed Computing

Other lines of research have used modal logic (in various forms) for distributedcomputing. Borghuis and Feijs’s Modal Type System for Networks [6] providesa logic and operational semantics5 for network tasks with stationary servicesand mobile data. They use 2, annotated with a location, to represent services.For example, 2o(A ⊃ B) means a function from A to B at the location o. Withno way of internalizing mobility as a proposition, the calculus limits mobiledata to base types. Services are similarly restricted to depth-one arrow types.By using 2 for mobile code and 3 or at for stationary resources, we believeour resulting calculus is both simpler and more general.

5By way of compilation into shell scripts!

34

Cardelli and Gordon [10] provide an early example of using modal logic forreasoning about programs spatially, later refined by Caires and Cardelli [8, 9].They do not take a propositions-as-types view of their logic; instead, they startfrom a process calculus, mobile ambients [10], and develop a classical logic forreasoning about their behaviors. Therefore, their modal logic is very differentfrom intuitionistic S5 and includes connectives for stating temporal properties,security properties, and properties of parallel compositions. In contrast, theproposed work gives a computational interpretation of the logic as a type sys-tem in the tradition of ML.

Hennessy et al. [19] developed a distributed version of the π-calculus andimpose a complex static type system in order to constrain and describe be-havior. Similarly, Schmitt and Stefani [40] develop a distributed, higher-orderversion of the Join Calculus with a complex behavioral type system. In compar-ison, our system is much simpler, eliminating the complexities of concurrency,access control, and related considerations. By basing our system on the Curry-Howard correspondence, we have a purely logical analysis and, furthermore,propose a straightforward path for integration into a full-scale functional lan-guage for realistic programs.

Moody [26] gives a system based on the constructive modal logic S4 dueto Pfenning and Davies [36]. In contrast to our explicit world formalism, thislanguage is based on judgments A true (here), A poss (somewhere), and A valid(everywhere). The operational semantics of his system takes the form of a pro-cess calculus with nondeterminism, concurrency and synchronization; a sig-nificantly different approach from our sequential model. From the standpointof a multiple world semantics, the accessibility relation of S4 satisfies only re-flexivity and transitivity, not symmetry. From the computational point of view,accessibility in his work describes process interdependence rather than con-nections between actual network locations. Programs are therefore somewhathigher-level and express potential mobility instead of explicit code motion as inthe get construct. In particular, due to the lack of symmetry it is not possibleto go back to a source world after a potentially remote procedure call except byreturning a value.

Jia and Walker [21] give a judgmental account of an explicit world S5-basedlogic that is very similar to ours. The main difference is in the envisioned oper-ational semantics. Theirs is a process calculus admitting “action-at-a-distance,”where a primitive notion is the passive synchronization of two processes: onethat waits for the value of a label, and one that computes it. In comparison, wehave designed a semantics that we believe is more amenable to standard func-tional programming style. Our decomposition of the rules for the modalitiesmeans that we have only one primitive that induces communication betweennodes, and it has a simple, active, operational behavior. To our knowledge,there is no implementation of their calculus as a programming language.

35

10 Conclusion

I have presented a plan for the design and construction of a language for spa-tially distributed computing. The language is designed from first principleson a foundation of logic, using the modal logic Intuitionistic S5 for its abilityto represent spatial reasoning. Through its modal type system, ML5 is able tostatically control access to location-sensitive resources. The proposed work isnovel, feasible, and has both theory and practice components. I conclude witha rough timeline for the completion of the thesis.

Timeline. This project consists of a substantial body of theory (a new lan-guage design and associated logics), and implementation (a compiler and dis-tributed runtime). For the purposes of the thesis, these parts may be of vary-ing quality. For instance, a high-performance ML compiler alone can requiredozens of man-years of work, but is not required to support the thesis. For thework to be done, I adopt a taxonomy that prioritizes tasks into the followingcategories:

• Primary, meaning that this is a central contribution of original work, de-serving maximal attention

• Secondary, meaning an interesting and original contribution that is notnecessary, but that would strengthen the thesis. Many of these items willbecome “future work”

• Tarpit, meaning a notoriously difficult or involved problem, and so I willonly do the bare minimum to make the system usable, leaving the prob-lem open for “future work”

• Solved, meaning a task that is well-understood and standard, and soI will do only the bare minimum to make the system usable (or re-useexisting technology)

The following is a plan for completing the proposed work, annotated witha basic strategy according to the above. Rather than give time estimates, I giveapproximate fractions of the total time.

Theory: Language and Logic DesignComplete Twelf proofs and add other types.Primary. What needs to be done here is to work the va-lidity judgment through the phases of the formalizedcompiler (elaboration, CPS conversion). Since I haveworked these cases out on paper, I do not foresee anyproblems. Adding sums and recursive types (etc.) tothe language and proofs will be standard.

6%

36

Network signatures and separate compilation.Secondary. The language as presented does not providea way of specifying the initial configuration of resourcesin the network. The language should be extended togive a way to describe the local resources at other hosts,and to compile and link against this interface to them.My recent work on a separate compilation system forStandard ML [43] should help provide guidance in de-signing this.

6%?

Implementation: CompilerParser, elaboration, CPS, closure conversion.Primary. I can re-use some of the code from Hemlock(for instance, the pattern matcher) here.

19%

Standard IL Optimizations.Solved. I will spend a small amount of time implement-ing the optimizations that make the biggest differencefor the least effort (dead code elimination), but this isonly to make the compiler suitable for reasonable appli-cations.

2%

Optimizations of mobile primitives.Secondary. It may be important to do special optimiza-tions for our domain (closure representation, dead andconstant get s, etc.). Time permitting, I would like towork on this, since it is likely that there is much low-hanging fruit.

2%?

Certifying back-end.Solved. I would like to re-use Joe Vanderwaart’s popcornTALT compiler as the back-end, if possible. Although Iwill need to make some changes to support primitivesnecessary for ML5-specific features (marshalling), I hopethat these will be relatively minor, and that the bulk ofboilerplate code will be taken care of.

13%

Implementation: Runtime

37

Basic Infrastructure.Primary. Some basic infrastructure is required to runML5 programs. This would allow a program to arriveon the target machine, be certified, and executed. Al-though we cannot use the ConCert v2 system for this,much of that code can be repurposed to build the ML5runtime. (This runtime is also much simpler, barringthe points below, because it does not need to implementwork-stealing, P2P node discovery, a distributed hashtable, or fault tolerance.) Still, this will be a significantimplementation effort.

13%

Concurrency support.Tarpit. Good support for concurrency opens up the sys-tem to a large number of design and implementation is-sues which cannot reasonably fit within the time frame,and which are anyway outside the scope of the thesis.Some basic concurrency support may however be nec-essary to write a compelling example application.

∞%

Failure tolerance.Tarpit. We have designed a fault-tolerant network withthe ConCert v2 system. However, the ideas are largelyincompatible here because we support effects; fault tol-erance would need to be able to log, roll-back, and re-play effects. While there are some known techniques forthis (such as message logging [22]), they would makethe implementation substantially more complex than itneeds to be to support the thesis.6

∞%

Garbage collection.Tarpit. This is a difficult problem, but a basic solutionwill be necessary to make the system usable. I will be-gin with the simplest possible collector and, when de-signing the runtime, make sure not to preclude moreadvanced collectors should the need for them arise.

6%

Application

6Some very simple support for enabling application authors to handle failure may be possibleby simply raising a handleable exception when a get does not succeed?

38

Application.Primary. The primary difficulty will be finding an in-teresting problem to solve that does not require sophis-ticated concurrency or fault tolerance, since I want toavoid those.

6%

DissertationWriting. 26%

References[1] Alice web site, 2005. URL: http://www.ps.uni-sb.de/alice/.

[2] Alice web site: Distribution, 2005. URL:http://www.ps.uni-sb.de/alice/manual/distribution.html.

[3] David P. Anderson. BOINC: A system for public-resource computing andstorage. In Proceedings of the 5th IEEE/ACM International Workshop on GridComputing, Pittsburgh, USA, November 2004.

[4] Andrew Appel. Compiling With Continuations. Cambridge University Press,Cambridge, 1992.

[5] Robert D. Blumofe and Philip A. Lisiecki. Adaptive and reliable parallelcomputing on networks of workstations. In USENIX 1997 Annual TechnicalConference on UNIX and Advanced Computing Systems, pages 133–147, Anaheim,California, 1997.

[6] Tijn Borghuis and Loe M. G. Feijs. A constructive logic for services andinformation flow in computer networks. The Computer Journal, 43(4):274–289,2000.

[7] D. Box. Understanding COM. Addison-Wesley, Reading, MA, 1997.

[8] Luıs Caires and Luca Cardelli. A spatial logic for concurrency (part I). InTheoretical Aspects of Computer Software (TACS), pages 1–37. Springer-Verlag LNCS2215, October 2001.

[9] Luıs Caires and Luca Cardelli. A spatial logic for concurrency (part II). InProceedings of the 13th International Conference on Concurrency Theory (CONCUR),pages 209–225, Brno, Czech Republic, August 2002. Springer-Verlag LNCS 2421.

[10] Luca Cardelli and Andrew D. Gordon. Anytime, anywhere. modal logics formobile ambients. In Proceedings of the 27th Symposium on Principles of ProgrammingLanguages (POPL), pages 365–377. ACM Press, 2000.

[11] B. Chang, K. Crary, M. DeLap, R. Harper, J. Liszka, T. Murphy VII, andF. Pfenning. Trustless grid computing in ConCert. In M. Parashar, editor, GridComputing – Grid 2002 Third International Workshop, pages 112–125, Berlin,November 2002. Springer-Verlag.

[12] ConCert project home page: Software, 2006. URL:http://msdn.microsoft.com/netframework/ .

[13] Karl Crary. Toward a foundational typed assembly language (expanded version).Technical Report CMU-CS-02-196, Carnegie Mellon University, 2002.

39

[14] Karl Crary, Michael Hicks, and Stephanie Weirich. Safe and flexible dynamiclinking of native code. In 2000 ACM SIGPLAN Workshop on Types in Compilation,September 2000.

[15] Karl Crary and Stephanie Weirich. Flexible type analysis. In InternationalConference on Functional Programming, pages 233–248, 1999.

[16] Jim Farley. Java Distributed Computing. O’Reilly, January 1998.

[17] Ian Foster and Carl Kesselman. The Globus project: a status report. FutureGeneration Computer Systems, 15(5–6):607–621, 1999.

[18] Ian Foster and Carl Kesselman, editors. The Grid: Blueprint for a New ComputingInfrastructure. Morgan Kaufmann, San Francisco, California, 1999.

[19] Matthew Hennessy, Julian Rathke, and Nobuko Yoshida. SafeDPi: A language forcontrolling mobile code. Report 02/2003, Department of Computer Science,University of Sussex, October 2003.

[20] Hybrid logics bibliography, 2005. URL: http://hylo.loria.fr/content/papers.php.

[21] Limin Jia and David Walker. Modal proofs as distributed programs (extendedabstract). European Symposium on Programming, 2004.

[22] David B. Johnson and Willy Zwaenepoel. Recovery in distributed systems usingoptimistic message logging and checkpointing. In Proc. 7th Annual ACM Symp. onPrinciples of Distributed Computing, pages 171–181, Toronto (Canada), 1988.

[23] Clarence Irving Lewis. A Survey of Symbolic Logic. University of California Press,1918.

[24] Robin Milner, Mads Tofte, Robert Harper, and David MacQueen. The Definition ofStandard ML (Revised). MIT Press, Cambridge, Massachusetts, 1997.

[25] Modal types for mobile code: Supplementary twelf source, 2006. URL:http://tom7.org/proposal/.

[26] Jonathan Moody. Modal logic as a basis for distributed computation. TechnicalReport CMU-CS-03-194, Carnegie Mellon University, October 2003.

[27] Greg Morrisett. Compiling with Types. PhD thesis, Carnegie Mellon University,December 1995. Available as CMU Technical Report CMU–CS–95–226.

[28] Greg Morrisett, David Walker, Karl Crary, and Neal Glew. From System F totyped assembly language. ACM Transactions on Programming Languages andSystems, 21(3):527–568, May 1999.

[29] Tom Murphy, VII. Functional grid programming with ConCert, 2004.Unpublished draft; http://tom7.org/papers/ .

[30] Tom Murphy, VII, Karl Crary, and Robert Harper. Distributed control flow withclassical modal logic. In Luke Ong, editor, 14th Annual Conference of the EuropeanAssociation for Computer Science Logic (CSL 2005), Lecture Notes in ComputerScience. Springer, August 2005.

[31] Tom Murphy, VII, Karl Crary, Robert Harper, and Frank Pfenning. A symmetricmodal lambda calculus for distributed computing. In Proceedings of the 19th IEEESymposium on Logic in Computer Science (LICS 2004). IEEE Press, July 2004.

[32] George C. Necula. Proof-carrying code. In Proceedings of the 24th ACMSIGPLAN-SIGACT Symposium on Principles of Programming Langauges (POPL ’97),pages 106–119, Paris, January 1997.

40

[33] .Net web site, 2006. URL: http://msdn.microsoft.com/netframework/ .

[34] Sungwoo Park. A modal language for the safety of mobile values. TechnicalReport CMU-CS-05-124, Carnegie Mellon, Pittsburgh, Pennsylvania, USA, May2005.

[35] Leaf Petersen. Certifying Compilation for Standard ML in a Type Analysis Framework.PhD thesis, Carnegie Mellon University, May 2005. Available as CMU TechnicalReport CMU–CS–05–135.

[36] Frank Pfenning and Rowan Davies. A judgmental reconstruction of modal logic.Mathematical Structures in Computer Science, 11:511–540, 2001. Notes to an invitedtalk at the Workshop on Intuitionistic Modal Logics and Applications (IMLA’99),Trento, Italy, July 1999.

[37] David Plainfosse and Marc Shapiro. A survey of distributed collectiontechniques. Technical report, BROADCAST, 1994.

[38] John Reppy. Concurrent Programming in ML. Cambridge University Press, 1999.

[39] Andreas Rossberg, Didier Le Botlan, Guido Tack, Thorsten Brunklaus, and GertSmolka. Alice Through the Looking Glass, volume 5 of Trends in FunctionalProgramming. Intellect, Munich, Germany, 2004.

[40] Alan Schmitt and Jean-Bernard Stefani. The M-calculus: A higher-orderdistributed process calculus. In Conference Record of the 30th Symposium onPrinciples of progr ammming Languages, pages 50–61, New Orleans, Louisiana,January 2003. ACM Press.

[41] Peter Sewell, James J. Leifer, Keith Wansbrough, Francesco Zappa Nardelli, MairAllen-Williams, Pierre Habouzit, and Viktor Vafeiadis. Acute: high-levelprogramming language design for distributed computation. In InternationalConference on Functional Programming (ICFP) 2005, Tallinn, Estonia, September2005.

[42] Alex Simpson. The Proof Theory and Semantics of Intuitionistic Modal Logic. PhDthesis, University of Edinburgh, 1994.

[43] David Swasey, Tom Murphy, VII, Karl Crary, and Robert Harper. A separatecompilation extension to Standard ML. Technical Report CMU-CS-06-104,Carnegie Mellon University, January 2006.

[44] Joseph C. Vanderwaart and Karl Crary. Automated and certified conformance toresponsiveness policies. In Proceedings of the ACM SIGPLAN workshop on types inlanguage design and implementation (TLDI), 2005.

[45] Steve Vinoski. CORBA: integrating diverse applications within distributedheterogeneous environments. IEEE Communications Magazine, 14(2), 1997.

[46] W3C Web Service Description Working Group, David Booth and Canyang KevinLiu, eds. Web services description language (WSDL) version 2.0 part 0: primer.Technical Report WD-wsdl20-primer-20050510, W3C, URL:http://www.w3.org/TR/wsdl20-primer, May 2005.

[47] W3C web services working group, 2002. URL: http://www.w3.org/2002/ws/.

[48] P. Wadler and S. Blott. How to make ad-hoc polymorphism less ad-hoc. InConference Record of the 16th Annual ACM Symposium on Principles of ProgrammingLanguages, pages 60–76. ACM, January 1989.

41

[49] Ken Wakita, Takashi Asano, and Masataka Sassa. D’Caml: A native distributedML compiler for heterogeneous environment. In Patrick Amestoy, PhilippeBerger, Michel J. Dayde, Iain S. Duff, Valerie Fraysse, Luc Giraud, and DanielRuiz, editors, Euro-Par 1999 Parallel Processing, 5th International Euro-ParConference, volume 1685 of Lecture Notes in Computer Science, pages 914–924.Springer, 1999.

[50] Zhonghua Yang and Keith Duddy. CORBA: A platform for distributed objectcomputing (a state-of-the-art report on OMG/CORBA). Operating Systems Review,30(2):4–31, 1996.

42

A Intuitionistic S5

(a)

Γ, ω world ` M : A@ω

Γ ` box ω.M : 2A@w2 I

Γ ` M : 2A@wΓ ` unbox M : A@w

2 E

Γ ` A true@w′

Γ ` 3A true@w3 I

Γ ` 3A true@w′

Γ, ω world, A true@ω ` C true@wΓ ` C true@w

3 E

Γ, A true@w ` B true@wΓ ` A ⊃ B true@w

⊃ IΓ ` A ⊃ B true@w Γ ` A true@w

Γ ` B true@w⊃ E

Γ ` A true@w Γ ` B true@wΓ ` A ∧B true@w

∧ IΓ ` A ∧B true@w

Γ ` A true@w∧ E1

Γ ` A ∧B true@wΓ ` B true@w

∧ E2Γ ` A true@w

Γ ` A ∨B true@w∨ I1

Γ ` B true@wΓ ` A ∨B true@w

∨ I2

Γ ` A ∨B true@w′

Γ, A true@w′ ` C @wΓ, B true@w′ ` C @w

Γ ` C true@w∨ E

(b)

Γ ` A true@w′

Γ ` A atw′ true@wat I

Γ ` A atw true@w′

Γ ` A true@wat E

Figure 6: (a) The standard presentation of Intuitionistic S5, as used by e.g. Simp-son [42]. (b) The extension to add the at modality, as in e.g. Jia and Walker [21]

43

B Internal Language

exps M,N ::= leta x = M in N| v| MN| fst M | snd M| M [w]| unpack M as ω, x in N| get[w;M ]N| localhost()| letc u = M in N| mkpair(M,N)

valid exps S ::= mobc M| valid z

values v ::= 〈v1, v2〉| holdwv| λx.M| Λω.v| w| u | x | z| ()| pack w, v as ∃ω.A| cir S

valid vals z ::= vv ω.vtypes A,B ::= A×B | A → B

| ∀ω.A | ∃ω.A| w addr | unit| fA

Figure 7: The syntax of the Internal Language as formalized in the Twelf code.In this version, we use a separate syntactic class z for valid values. These areinstantiated at the current world when used as values

For the full static semantics for machine states and the statement of typesafety, see the Twelf code [25].

44

stack frames f ::= get[w; ◦] M| ret[w] ◦| ◦ N | v ◦| ◦[w]| fst ◦ | snd ◦| mkpair(◦, N) | mkpair(v, ◦)| leta x = ◦ in N| unpack ◦ as ω, x in N| letc u = ◦ in N| letc mob u = ◦ in N

stacks s ::= finish | s � f

Figure 8: Stack syntax for the internal language, used to define the dynamicsemantics

[[holdwv]]MV = vv ω.holdwv[[〈v1, v2〉]]MV = vv ω.〈[[v1]]MV, [[v2]]MV〉

[[Λω.v]]MV = vv ω′.Λω.[[v]]MV

[[pack w, v as ∃ω.A]]MV = vv ω′.pack w, [[v]]MV as ∃ω.A[[w]]MV = vv ω.w[[z]]MV = z

Figure 9: Mobilization of values in the internal language. Values of certainforms can be transformed into valid values; the partial function [[·]]MV performsthis mobilization. In each case, the bound world is unused in the body of thevalid value

45

w::s; localhost 7→ w ::s; ww::s; unpack M as ω, x in N 7→ w ::s � unpack ◦ as ω, x in N ;Mw::s � unpack ◦ as ω, x in N ; 7→

pack w, v as ∃ω.A w ::s; [ v/x]Nw::s; fst M 7→ w ::s � fst ◦;Mw::s; snd M 7→ w ::s � snd ◦;Mw::s � fst ◦; 〈v1, v2〉 7→ w ::s; v1

w::s � snd ◦; 〈v1, v2〉 7→ w ::s; v2

w::s;MN 7→ w ::s � ◦ N ;Mw::s � ◦ N ;λx.M 7→ w ::s � λx.M ◦;Nw::s � λx.M ◦; v 7→ w ::s; [ v/x]Mw::s;M [w] 7→ w ::s � ◦[w];Mw::s � ◦[w]; Λω.v 7→ w ::s; [ w/ω]vw::s; get[w,M ]N 7→ w ::s � get[w, ◦]N ;Mw::s � get[w, ◦]N ; w′ 7→ w′::s � ret[w] ◦;Nw::s � ret[w′] ◦; v 7→ w′::s; [[v]]MV

w::s; mkpair(M,N) 7→ w ::s � mkpair(◦, N);Mw::s � mkpair(◦, N); v 7→ w ::s � mkpair(v, ◦);Nw::s � mkpair(v1, ◦); v2 7→ w ::s; 〈v1, v2〉w::s; letc u = valid z in N 7→ w ::s; [ z/u]Nw::s; letc u = mobc M in N ; 7→ w ::s � letc mob u = ◦ in N ;Mw::s � letc mob u = ◦ in N ; v 7→ w ::s; [ [[v]]MV/u]Nw::s; leta x = M in N 7→ w ::s � leta x = ◦ in N ;Mw::s � leta x = ◦ in N ; holdwv 7→ w ::s; [ v/x]Nw::s; vv ω.v 7→ w ::s; [ w/ω]vw::finish; v 7→ w ::finish; v

Figure 10: Dynamic semantics for the internal language, given in terms of arelation 7→ between machine states. A machine state takes the form w::s;M orw::s; v where w is the current world of evaluation, s is the current stack, andM is the expression to be evaluated or v the value to be returned. The final rulesteps from a finished machine to itself, which simplifies the statement of typesafety

46

C CPS Language

[[ ω.v/u]]w liftu′ = v′ in c = liftu′ = [[ ω.v/u]]wv′ in [[ ω.v/u]]wc[[ ω.v/u]]whalt = halt

[[ ω.v/u]]wgo[w′; va] c = go[w′; [[ ω.v/u]]wva] [[ ω.v/u]]w′c· · ·

[[ ω.v/u]]wu = [ w/ω]v[[ ω.v/u]]wu′ = u′ (u 6= u′)

[[ ω.v/u]]wλx.c = λx.[[ ω.v/u]]wc[[ ω.v/u]]wx = x[[ ω.v/u]]ww = w

[[ ω.v/u]]wholdw′v′ = holdw′ [[ ω.v/u]]w′v′

[[ ω.v/u]]wcval ω′.v′ = cval ω′.[[ ω.v/u]]ω′v′

· · ·

Figure 11: Instantiating substitution for valid variables in the the CPS lan-guage. This represents one of two ways used to formulate the dynamic se-mantics for valid variables. (The other, used exclusively in the Twelf formal-ization, can be seen in the semantics for the Internal Language in Figure 10.)In this case, the instantiating substitution [[ ω.v/u]]wc substitutes for the variableu within c, by instantiating the valid value ω.v at the worlds where it is used.The parameter w indicates the current world in the substitution function. Sub-stitution is also defined over values. Note that the instantiation is purely static;in an implementation, the same exact value can be used at each occurrence ofu. As usual, we assume the freshness of bound variables in order to avoid cap-ture; the variable u′ in the case for lift, for instance, is assumed to not appearin v

Property 4 (Type Safety of CPS Language)(a) If · ` c@w (in CPS)

then there exists w′, c′ such thatw::c 7→ w′::c′.

(b) If · ` c@w (in CPS)and w::c 7→ w′::c′

then · ` c′@w′.

47

w::leta x = holdwv in c 7→ w::[ v/x]cw:: letgu = cval ω′.v in c 7→ w::[[ ω′.v/u]]wc

w:: liftu = v in c 7→ w::[ v/u]cw::let x = fst 〈v1, v2〉 in c 7→ w::[ v1/x]cw::let x = snd 〈v1, v2〉 in c 7→ w::[ v2/x]c

w::let x = mkpair v1, v2 in c 7→ w::[ 〈v1,v2〉/x]cw::let x = localhost() in c 7→ w::[ w/x]c

w::go[w1; w1] c 7→ w1::cw::call (λx.c)(v) 7→ w::[ v/x]c

w::halt 7→ w::halt

Figure 12: The dynamic semantics for the CPS language. It is given in terms of astepping relation 7→ between pairs of CPS machines of the form w::c, where wis the current world of evaluation and c is the current continuation expression.We give only the rules for the constructs that appear in Figure 3. The expressionhalt has a self-transition for the ease of stating type safety (Property 4)

48