Modal Logic: Implications for Design of a Language for Distributed Computation Jonathan Moody (with Frank Pfenning) Department of Computer Science Carnegie Mellon University Modal Logic: Implications for Design of a Language for Distributed Computation p.1/53
Talk Outline Concepts of modal logic Intuitionistic formalism Distributed programming Conclusions Modal Logic: Implications for Design of a Language for Distributed Computation p.2/53
Concepts of modal logic Modal logic(s) distinguish modes of truth. For the generalized modal logic (S4) these modes of truth are explained by referring to (abstract) worlds : Truth in all (accessible) worlds. Truth in this world. Truth in some (accessible) world. Modal Logic: Implications for Design of a Language for Distributed Computation p.3/53
Concepts: A Kripke model W1 W2 W3 W4 Worlds of the Kripke structure Modal Logic: Implications for Design of a Language for Distributed Computation p.4/53
Concepts: A Kripke model W1 W2 W3 W4 Accessibility between worlds Modal Logic: Implications for Design of a Language for Distributed Computation p.4/53
Concepts: A Kripke model W1 A C W2 C W3 B C W4 C D Primitive assumptions Modal Logic: Implications for Design of a Language for Distributed Computation p.4/53
Concepts: A Kripke model W1 A C W2 C W3 B C W4 C D From the perspective of world... Modal Logic: Implications for Design of a Language for Distributed Computation p.4/53
Concepts: A Kripke model W1 A C W2 C W3 B C W4 C D and are true here ( ) Modal Logic: Implications for Design of a Language for Distributed Computation p.4/53
Concepts: Modal propositions By introducing new forms of proposition, we can make statements about other worlds. true in all accessible worlds. true in some accessible world. Modal Logic: Implications for Design of a Language for Distributed Computation p.5/53
Concepts: A Kripke model W1 A C W2 C W3 B C W4 C D true at true at because... (refl. & trans.) Modal Logic: Implications for Design of a Language for Distributed Computation p.6/53
Concepts: A Kripke model W1 A C W2 C W3 B C W4 C D true at true at because... (reflexivity) Modal Logic: Implications for Design of a Language for Distributed Computation p.6/53
Concepts: A Kripke model W1 A C W2 C W3 B C W4 C D true at true at because... Modal Logic: Implications for Design of a Language for Distributed Computation p.6/53
Concepts: A Kripke model W1 A C W2 C W3 B C W4 C D true at true at because... (transitivity) Modal Logic: Implications for Design of a Language for Distributed Computation p.6/53
Concepts: More concrete models But what are the worlds we refer to? It is quite possible to remain abstract, but for applications it helps to have a class of worlds in mind. Temporal properties (worlds are moments, ordering determines accessibility) Stateful computation (worlds are states, effects determine accessibility) Modal Logic: Implications for Design of a Language for Distributed Computation p.7/53
Concepts: More concrete models For distributed computation, we adopt a spatial interpretation of worlds. Modal Logic: Implications for Design of a Language for Distributed Computation p.8/53
Concepts: More concrete models For distributed computation, we adopt a spatial interpretation of worlds. Worlds are: where program fragments reside, where these fragments are well-typed, and hence where evaluation may happen. Modal Logic: Implications for Design of a Language for Distributed Computation p.8/53
Concepts: More concrete models For distributed computation, we adopt a spatial interpretation of worlds. Worlds are: where program fragments reside, where these fragments are well-typed, and hence where evaluation may happen. Accessibility (hypothesis): the capability to move program fragments between worlds. Modal Logic: Implications for Design of a Language for Distributed Computation p.8/53
Talk Outline Intuitionistic formalism Judgements and propositions Language of proof terms Operational reading Properties Modal Logic: Implications for Design of a Language for Distributed Computation p.9/53
Judgements and propositions The meaning of propositions in the intuitionistic formulation is consistent with those of the classical formulation. However, we are now in an intuitionistic setting... We focus on the form of proofs, not truth relative to a particular model. Modal Logic: Implications for Design of a Language for Distributed Computation p.10/53
Judgements and propositions Judgements formalize the modes of truth: (true everywhere) (true here) (true somewhere) Propositions of the logic remain the same: (internalizes ) (internalizes ) (internalizes entailment) Modal Logic: Implications for Design of a Language for Distributed Computation p.11/53
Judgements and propositions Hypothetical judgements are represented as: (or ) holds global hypotheses ( holds local hypotheses ( ) ) Modal Logic: Implications for Design of a Language for Distributed Computation p.12/53
Language of proof terms Via a Curry-Howard isomorphism we can: Pass from to And from to Terms and expressions are simultaneously proof objects and programs. Modal Logic: Implications for Design of a Language for Distributed Computation p.13/53
Language of proof terms Quick overview of syntax (more depth later): Term Expr. box dia let box = in { } let box = in let dia = in Modal Logic: Implications for Design of a Language for Distributed Computation p.14/53
Operational reading Principles of the operational semantics: We may interpret terms/expressions only in a location where they make sense, that is, where they establish Evaluation at separate worlds proceeds concurrently. Modal Logic: Implications for Design of a Language for Distributed Computation p.15/53
!! Operational reading: Notation Process notation A process labeled containing term. Each process represents a (possibly) distinct world. Transition relation are process configurations (collections of processes). Modal Logic: Implications for Design of a Language for Distributed Computation p.16/53
# " Operational reading: Notation Evaluation context notation (Term) values of the language: tvalue box tvalue dia tvalue tvalue Note that language of terms is extended: Result label is considered a term value. Allows processes to refer to one another. Modal Logic: Implications for Design of a Language for Distributed Computation p.17/53
Operational reading: Local variables and intro/elim:! $&% ' ( Modal Logic: Implications for Design of a Language for Distributed Computation p.18/53
Operational reading : Local reduction step:!! ( )!* )!* tvalue " # " " + #! #, ' ' Modal Logic: Implications for Design of a Language for Distributed Computation p.19/53
- ' ( Operational reading: Global variables and intro/elim: $&%! /. box let box = in Modal Logic: Implications for Design of a Language for Distributed Computation p.20/53
( 5 # " # # # + " Operational reading: Local reduction step: /. box let box = box in box let box fresh = in 3&4 2 0&1 "" Modal Logic: Implications for Design of a Language for Distributed Computation p.21/53
87 %6 # " # # Operational reading: Synchronization on result labels ( tvalue " ) Immediate synch. is not required ( tvalue). We have a choice between synchronization ( ) or the usual reduction step. Concurrency is a secondary effect of the spatial interpretation, not logically essential. " Modal Logic: Implications for Design of a Language for Distributed Computation p.22/53
Operational reading: Notation Now considering the expression fragment of the language... Having means that E makes sense somewhere (but not necessarily here ). We may not interpret expressions until they are placed in the proper context. Modal Logic: Implications for Design of a Language for Distributed Computation p.23/53
0 0 0 # " # " Operational reading: Notation It is convenient to introduce expression variants of: Processes: and Evaluation contexts: and Expression values: tvalue { } evalue Modal Logic: Implications for Design of a Language for Distributed Computation p.24/53
6 6 4' 9 Operational reading: Relationship between truth and possibility: { } Global variables bound in expressions: let box = in Modal Logic: Implications for Design of a Language for Distributed Computation p.25/53
( Operational reading: introduction and elimination: dia let dia = in Modal Logic: Implications for Design of a Language for Distributed Computation p.26/53
( 0 0 0 + 0 0 0 Operational reading: Local reduction step: dia let dia = dia in dia let dia fresh = in, :; 2 0 1 Note: location is not arbitrary. Modal Logic: Implications for Design of a Language for Distributed Computation p.27/53
Language of proof terms In summary: Term Expr. box dia let box = in { } let box = in let dia = in Modal Logic: Implications for Design of a Language for Distributed Computation p.28/53
0. 0 Properties Typing for process configurations ( =< ) Conf. Typing Result labels Location labels (logical validity). (logical possibility). Modal Logic: Implications for Design of a Language for Distributed Computation p.29/53
!!!!! Properties Type preservation holds for If and then (where < < Proof depends on: Various substitution properties (from previous work). ). : Modal Logic: Implications for Design of a Language for Distributed Computation p.30/53
0 0 0 Properties Terminal processes: tvalue terminal evalue terminal terminal Modal Logic: Implications for Design of a Language for Distributed Computation p.31/53
! Properties Progress holds for well-formed config. : if then or terminal < Proof depends on: requires labels to be non-cyclic (similar to heap typing). Thus imposes an ordering on processes in which permits induction. < < Modal Logic: Implications for Design of a Language for Distributed Computation p.32/53
! Properties Confluence (plausible but not proved) permits non-deterministic, interleaved evaluation, but the results are always the same (modulo synchronization). Essentially there are only two forms of choice: Which process to focus on. Performing synchronization or the usual reduction step. Modal Logic: Implications for Design of a Language for Distributed Computation p.33/53
Talk Outline Distributed programming Marshalling The logical solution Examples Modal Logic: Implications for Design of a Language for Distributed Computation p.34/53
Distributed Programming From the perspective of ConCert, remote evaluation is the key. To support remote evaluation, we need mechanisms for: Code distribution Parameter distribution Modal Logic: Implications for Design of a Language for Distributed Computation p.35/53
Marshalling Code distribution: Pre-distribute code (RPC,Globus). Distribute at runtime (Concert). In either case, it is assumed that code is global (ignoring binary compatibility). Parameter distribution: Marshalling some things is tricky. Hence implementors usually make a marshallable/non-marshallable distinction. Modal Logic: Implications for Design of a Language for Distributed Computation p.36/53
Marshalling The marshallable/non-marshallable distinction is critical: Semantic anomalies if you get it wrong. Code mobility depends on parameter mobility. Modal Logic: Implications for Design of a Language for Distributed Computation p.37/53
Marshalling The key is to recognize that some things are inherently localized. Need to ask ourselves: Which objects can sensibly be transferred between locations? Modal Logic: Implications for Design of a Language for Distributed Computation p.38/53
Marshalling The key is to recognize that some things are inherently localized. Need to ask ourselves: Which objects can sensibly be transferred between locations? integers, strings, (etc.)? Modal Logic: Implications for Design of a Language for Distributed Computation p.38/53
Marshalling The key is to recognize that some things are inherently localized. Need to ask ourselves: Which objects can sensibly be transferred between locations? integers, strings, (etc.)? yes. Modal Logic: Implications for Design of a Language for Distributed Computation p.38/53
Marshalling The key is to recognize that some things are inherently localized. Need to ask ourselves: Which objects can sensibly be transferred between locations? integers, strings, (etc.)? yes. functions? Modal Logic: Implications for Design of a Language for Distributed Computation p.38/53
Marshalling The key is to recognize that some things are inherently localized. Need to ask ourselves: Which objects can sensibly be transferred between locations? integers, strings, (etc.)? yes. functions? depends on env. of closure. Modal Logic: Implications for Design of a Language for Distributed Computation p.38/53
Marshalling The key is to recognize that some things are inherently localized. Need to ask ourselves: Which objects can sensibly be transferred between locations? integers, strings, (etc.)? yes. functions? depends on env. of closure. heap addresses? Modal Logic: Implications for Design of a Language for Distributed Computation p.38/53
Marshalling The key is to recognize that some things are inherently localized. Need to ask ourselves: Which objects can sensibly be transferred between locations? integers, strings, (etc.)? yes. functions? depends on env. of closure. heap addresses? no. Modal Logic: Implications for Design of a Language for Distributed Computation p.38/53
Marshalling The key is to recognize that some things are inherently localized. Need to ask ourselves: Which objects can sensibly be transferred between locations? integers, strings, (etc.)? yes. functions? depends on env. of closure. heap addresses? no. file handles? Modal Logic: Implications for Design of a Language for Distributed Computation p.38/53
Marshalling The key is to recognize that some things are inherently localized. Need to ask ourselves: Which objects can sensibly be transferred between locations? integers, strings, (etc.)? yes. functions? depends on env. of closure. heap addresses? no. file handles? no. Modal Logic: Implications for Design of a Language for Distributed Computation p.38/53
The logical solution The language of modal logic reflects (and resolves) these issues! Modal Logic: Implications for Design of a Language for Distributed Computation p.39/53
The logical solution The language of modal logic reflects (and resolves) these issues! The expressions of our language have the desired properties! Modal Logic: Implications for Design of a Language for Distributed Computation p.39/53
The logical solution The language of modal logic reflects (and resolves) these issues! The expressions of our language have the desired properties! Benefits of the logical approach: We get a clean type-analysis framework automatically. Suggests two forms of code mobility, one of which is not so obvious. Modal Logic: Implications for Design of a Language for Distributed Computation p.39/53
( ( The logical solution Typing judgement reflects marshallable/non-marshallable distinction: /. box let dia = in permits only globally valid parameters. permits param. from a single location. Modal Logic: Implications for Design of a Language for Distributed Computation p.40/53
The logical solution Moreover, we have two forms of remote evaluation: let box = box in Ordinary spawn anywhere evaluation. let dia = dia in Sending code to the place where local resources reside. Modal Logic: Implications for Design of a Language for Distributed Computation p.41/53
Examples : Recursive Fibonacci fix n : int. let box u = n in if (u < 2) then u else let box a = box(fib (box(u-1))) in let box b = box(fib (box(u-2))) in (a + b) > fib :: int int. Modal Logic: Implications for Design of a Language for Distributed Computation p.42/53
@?? Examples: I/O Operations Assuming localized file handle: @ representing a let dia c = console in write c "Enter a number:"; write c "answer = "; write c (( x : int. M) (read c)) Modal Logic: Implications for Design of a Language for Distributed Computation p.43/53
A Examples: Callbacks Assuming a runtime boxing operation. @ let box callback = box (dia {( x : int. M)}) in (* jump to console location *) let dia c = console write c "Enter a number:"; let box n = lift (read c) in (* jump back to callback loc *) let dia cb = callback in {cb n} @, Modal Logic: Implications for Design of a Language for Distributed Computation p.44/53
Talk Outline Concepts of modal logic Intuitionistic formalism Distributed programming Conclusions Modal Logic: Implications for Design of a Language for Distributed Computation p.45/53
Conclusions Modal logic shows how to safely program with a combination of mobile and immobile entities. Restrictions of modal logic are not mandatory if you deny the existence of localized entities. Other ad-hoc solutions to marshalling/safety are possible. Novelty is in the logical explanation of distributed computation. Modal Logic: Implications for Design of a Language for Distributed Computation p.46/53
Conclusions The assumptions at the foundations of modal logic bore fruit: From, we have expressions (things with localized meaning). From, we have closed terms (which are fully mobile). Modal Logic: Implications for Design of a Language for Distributed Computation p.47/53
Conclusions : Future work More logically explicit (explicit worlds) Should allow more precise treatment of dia/letdia. Lower-level operational semantics (environments, stacks) Separate concurrency from distribution. Concurrency could be orthogonal to box/letbox. Modal Logic: Implications for Design of a Language for Distributed Computation p.48/53
B Conclusions Acknowledgements: Frank Pfenning and Rowan Davies: A Judgemental Reconstruction of Modal Logic Further Reading: Modal Logic as a Basis for Distributed Computation http://www.cs.cmu.edu/ jwmoody/doc/np/modalbasis.pdf Modal Logic: Implications for Design of a Language for Distributed Computation p.49/53
The End Modal Logic: Implications for Design of a Language for Distributed Computation p.50/53
# + " + + C + C + + Expression Substitution Expression substitution is defined: let dia let box { } = in let dia = in let box = in = in Modal Logic: Implications for Design of a Language for Distributed Computation p.51/53
none Modal Logic: Implications for Design of a Language for Distributed Computation p.52/53
none Modal Logic: Implications for Design of a Language for Distributed Computation p.53/53
none Modal Logic: Implications for Design of a Language for Distributed Computation p.53/53