Modal Logic: Implications for Design of a Language for Distributed Computation p.1/53

Size: px
Start display at page:

Download "Modal Logic: Implications for Design of a Language for Distributed Computation p.1/53"

Transcription

1 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

2 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

3 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

4 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 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

23 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

24 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

25 !! 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

26 # " 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

27 Operational reading: Local variables and intro/elim:! $&% ' ( Modal Logic: Implications for Design of a Language for Distributed Computation p.18/53

28 Operational reading : Local reduction step:!! ( )!* )!* tvalue " # " " + #! #, ' ' Modal Logic: Implications for Design of a Language for Distributed Computation p.19/53

29 - ' ( 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

30 ( 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

31 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

32 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

33 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

34 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

35 ( Operational reading: introduction and elimination: dia let dia = in Modal Logic: Implications for Design of a Language for Distributed Computation p.26/53

36 ( Operational reading: Local reduction step: dia let dia = dia in dia let dia fresh = in, :; Note: location is not arbitrary. Modal Logic: Implications for Design of a Language for Distributed Computation p.27/53

37 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

38 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

39 !!!!! 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

40 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

41 ! 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

42 ! 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

43 Talk Outline Distributed programming Marshalling The logical solution Examples Modal Logic: Implications for Design of a Language for Distributed Computation p.34/53

44 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

45 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

46 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

47 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

48 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

49 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

50 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

51 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

52 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

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

54 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

55 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

56 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

57 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

58 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

59 ( ( 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

60 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

61 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

62 @?? Examples: I/O Operations Assuming localized file 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

63 A Examples: Callbacks Assuming a runtime boxing 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 Modal Logic: Implications for Design of a Language for Distributed Computation p.44/53

64 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

65 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

66 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

67 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

68 B Conclusions Acknowledgements: Frank Pfenning and Rowan Davies: A Judgemental Reconstruction of Modal Logic Further Reading: Modal Logic as a Basis for Distributed Computation jwmoody/doc/np/modalbasis.pdf Modal Logic: Implications for Design of a Language for Distributed Computation p.49/53

69 The End Modal Logic: Implications for Design of a Language for Distributed Computation p.50/53

70 # + " + + 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

71 none Modal Logic: Implications for Design of a Language for Distributed Computation p.52/53

72 none Modal Logic: Implications for Design of a Language for Distributed Computation p.53/53

73 none Modal Logic: Implications for Design of a Language for Distributed Computation p.53/53

Meta-programming with Names and Necessity p.1

Meta-programming with Names and Necessity p.1 Meta-programming with Names and Necessity Aleksandar Nanevski Carnegie Mellon University ICFP, Pittsburgh, 05 October 2002 Meta-programming with Names and Necessity p.1 Meta-programming Manipulation of

More information

On the Logical Foundations of Staged Computation

On the Logical Foundations of Staged Computation On the Logical Foundations of Staged Computation Frank Pfenning PEPM 00, Boston, MA January 22, 2000 1. Introduction 2. Judgments and Propositions 3. Intensional Types 4. Run-Time Code Generation 5. The

More information

Lecture Notes on Computational Interpretations of Modalities

Lecture Notes on Computational Interpretations of Modalities Lecture Notes on Computational Interpretations of Modalities 15-816: Modal Logic Frank Pfenning Lecture 4 January 21, 2010 1 Introduction In this lecture we present the first two of many possible computational

More information

CLF: A logical framework for concurrent systems

CLF: A logical framework for concurrent systems CLF: A logical framework for concurrent systems Thesis Proposal Kevin Watkins Carnegie Mellon University Committee: Frank Pfenning, CMU (Chair) Stephen Brookes, CMU Robert Harper, CMU Gordon Plotkin, University

More information

Kripke-Style Contextual Modal Type Theory

Kripke-Style Contextual Modal Type Theory Kripke-Style Contextual Modal Type Theory YUITO MURASE THE UNIVERSITY OF TOKYO Agenda Background Logic Type System Future Plan/Related Work Background: Syntactical Metaprogramming Extend the syntax of

More information

Fundamental Concepts. Chapter 1

Fundamental Concepts. Chapter 1 Chapter 1 Fundamental Concepts This book is about the mathematical foundations of programming, with a special attention on computing with infinite objects. How can mathematics help in programming? There

More information

Intersections and Unions of Session Types

Intersections and Unions of Session Types Intersections and Unions of Session Types Coşku Acay Frank Pfenning Carnegie Mellon University School of Computer Science ITRS 2016 C. Acay & F. Pfenning (CMU) Intersections and Unions of Session Types

More information

Chapter 3: Propositional Languages

Chapter 3: Propositional Languages Chapter 3: Propositional Languages We define here a general notion of a propositional language. We show how to obtain, as specific cases, various languages for propositional classical logic and some non-classical

More information

1. Abstract syntax: deep structure and binding. 2. Static semantics: typing rules. 3. Dynamic semantics: execution rules.

1. Abstract syntax: deep structure and binding. 2. Static semantics: typing rules. 3. Dynamic semantics: execution rules. Introduction Formal definitions of programming languages have three parts: CMPSCI 630: Programming Languages Static and Dynamic Semantics Spring 2009 (with thanks to Robert Harper) 1. Abstract syntax:

More information

Modal Logic Revisited

Modal Logic Revisited Modal Logic Revisited Frank Pfenning The Scottfest In honor of Dana Scott on his 70th Birthday Pittsburgh, Pennsylvania October 12, 2002 1 Source [1] Dana Scott, Advice on Modal Logic. In: Philosophical

More information

Lecture Notes on Static and Dynamic Semantics

Lecture Notes on Static and Dynamic Semantics Lecture Notes on Static and Dynamic Semantics 15-312: Foundations of Programming Languages Frank Pfenning Lecture 4 September 9, 2004 In this lecture we illustrate the basic concepts underlying the static

More information

Lecture Notes on Aggregate Data Structures

Lecture Notes on Aggregate Data Structures Lecture Notes on Aggregate Data Structures 15-312: Foundations of Programming Languages Frank Pfenning Lecture 8 September 23, 2004 In this lecture we discuss various language extensions which make MinML

More information

Programming Languages Third Edition

Programming Languages Third Edition Programming Languages Third Edition Chapter 12 Formal Semantics Objectives Become familiar with a sample small language for the purpose of semantic specification Understand operational semantics Understand

More information

Proofs-Programs correspondance and Security

Proofs-Programs correspondance and Security Proofs-Programs correspondance and Security Jean-Baptiste Joinet Université de Lyon & Centre Cavaillès, École Normale Supérieure, Paris Third Cybersecurity Japanese-French meeting Formal methods session

More information

CMSC 330: Organization of Programming Languages. Operational Semantics

CMSC 330: Organization of Programming Languages. Operational Semantics CMSC 330: Organization of Programming Languages Operational Semantics Notes about Project 4, Parts 1 & 2 Still due today (7/2) Will not be graded until 7/11 (along with Part 3) You are strongly encouraged

More information

ICFP: G: Curry-Howard for Callbacks

ICFP: G: Curry-Howard for Callbacks ICFP: G: Curry-Howard for Callbacks Jennifer Paykin University of Pennsylvania jpaykin@seas.upenn.edu 1 Problem and motivation Event-driven programming has become an increasingly popular programming model

More information

Lecture Notes on Induction and Recursion

Lecture Notes on Induction and Recursion Lecture Notes on Induction and Recursion 15-317: Constructive Logic Frank Pfenning Lecture 7 September 19, 2017 1 Introduction At this point in the course we have developed a good formal understanding

More information

CS4215 Programming Language Implementation. Martin Henz

CS4215 Programming Language Implementation. Martin Henz CS4215 Programming Language Implementation Martin Henz Thursday 26 January, 2012 2 Chapter 4 The Language simpl In this chapter, we are exting the language epl in order to provide a more powerful programming

More information

Supplementary Notes on Exceptions

Supplementary Notes on Exceptions Supplementary Notes on Exceptions 15-312: Foundations of Programming Languages Frank Pfenning Lecture 9 September 25, 2002 In this lecture we first give an implementation of the C-machine for the fragment

More information

Chapter 2 The Language PCF

Chapter 2 The Language PCF Chapter 2 The Language PCF We will illustrate the various styles of semantics of programming languages with an example: the language PCF Programming language for computable functions, also called Mini-ML.

More information

Supplementary Notes on Abstract Syntax

Supplementary Notes on Abstract Syntax Supplementary Notes on Abstract Syntax 15-312: Foundations of Programming Languages Frank Pfenning Lecture 3 September 3, 2002 Grammars, as we have discussed them so far, define a formal language as a

More information

Lecture 1 Contracts. 1 A Mysterious Program : Principles of Imperative Computation (Spring 2018) Frank Pfenning

Lecture 1 Contracts. 1 A Mysterious Program : Principles of Imperative Computation (Spring 2018) Frank Pfenning Lecture 1 Contracts 15-122: Principles of Imperative Computation (Spring 2018) Frank Pfenning In these notes we review contracts, which we use to collectively denote function contracts, loop invariants,

More information

Operational Semantics

Operational Semantics 15-819K: Logic Programming Lecture 4 Operational Semantics Frank Pfenning September 7, 2006 In this lecture we begin in the quest to formally capture the operational semantics in order to prove properties

More information

The Substitution Model

The Substitution Model The Substitution Model Prof. Clarkson Fall 2017 Today s music: Substitute by The Who Review Previously in 3110: simple interpreter for expression language abstract syntax tree (AST) evaluation based on

More information

Extracting the Range of cps from Affine Typing

Extracting the Range of cps from Affine Typing Extracting the Range of cps from Affine Typing Extended Abstract Josh Berdine, Peter W. O Hearn Queen Mary, University of London {berdine, ohearn}@dcs.qmul.ac.uk Hayo Thielecke The University of Birmingham

More information

«Computer Science» Requirements for applicants by Innopolis University

«Computer Science» Requirements for applicants by Innopolis University «Computer Science» Requirements for applicants by Innopolis University Contents Architecture and Organization... 2 Digital Logic and Digital Systems... 2 Machine Level Representation of Data... 2 Assembly

More information

Logical Mobility and Locality Types

Logical Mobility and Locality Types Logical Mobility and Locality Types Jonathan Moody 1 jwmoody@cs.cmu.edu Computer Science Department Carnegie Mellon University 5000 Forbes Ave. Pittsburgh PA 15213-3891 (phone) 1-412-268-5942 TCS Track

More information

(Refer Slide Time: 4:00)

(Refer Slide Time: 4:00) Principles of Programming Languages Dr. S. Arun Kumar Department of Computer Science & Engineering Indian Institute of Technology, Delhi Lecture - 38 Meanings Let us look at abstracts namely functional

More information

Semantics via Syntax. f (4) = if define f (x) =2 x + 55.

Semantics via Syntax. f (4) = if define f (x) =2 x + 55. 1 Semantics via Syntax The specification of a programming language starts with its syntax. As every programmer knows, the syntax of a language comes in the shape of a variant of a BNF (Backus-Naur Form)

More information

Formal Syntax and Semantics of Programming Languages

Formal Syntax and Semantics of Programming Languages Formal Syntax and Semantics of Programming Languages Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson http://www.daimi.au.dk/~bra8130/wiley_book/wiley.html The While

More information

Handout 9: Imperative Programs and State

Handout 9: Imperative Programs and State 06-02552 Princ. of Progr. Languages (and Extended ) The University of Birmingham Spring Semester 2016-17 School of Computer Science c Uday Reddy2016-17 Handout 9: Imperative Programs and State Imperative

More information

Programming Languages

Programming Languages CSE 230: Winter 2008 Principles of Programming Languages Ocaml/HW #3 Q-A Session Push deadline = Mar 10 Session Mon 3pm? Lecture 15: Type Systems Ranjit Jhala UC San Diego Why Typed Languages? Development

More information

STABILITY AND PARADOX IN ALGORITHMIC LOGIC

STABILITY AND PARADOX IN ALGORITHMIC LOGIC STABILITY AND PARADOX IN ALGORITHMIC LOGIC WAYNE AITKEN, JEFFREY A. BARRETT Abstract. Algorithmic logic is the logic of basic statements concerning algorithms and the algorithmic rules of deduction between

More information

Principles of AI Planning. Principles of AI Planning. 7.1 How to obtain a heuristic. 7.2 Relaxed planning tasks. 7.1 How to obtain a heuristic

Principles of AI Planning. Principles of AI Planning. 7.1 How to obtain a heuristic. 7.2 Relaxed planning tasks. 7.1 How to obtain a heuristic Principles of AI Planning June 8th, 2010 7. Planning as search: relaxed planning tasks Principles of AI Planning 7. Planning as search: relaxed planning tasks Malte Helmert and Bernhard Nebel 7.1 How to

More information

Reflection in the Chomsky Hierarchy

Reflection in the Chomsky Hierarchy Reflection in the Chomsky Hierarchy Henk Barendregt Venanzio Capretta Dexter Kozen 1 Introduction We investigate which classes of formal languages in the Chomsky hierarchy are reflexive, that is, contain

More information

Lecture 1 Contracts : Principles of Imperative Computation (Fall 2018) Frank Pfenning

Lecture 1 Contracts : Principles of Imperative Computation (Fall 2018) Frank Pfenning Lecture 1 Contracts 15-122: Principles of Imperative Computation (Fall 2018) Frank Pfenning In these notes we review contracts, which we use to collectively denote function contracts, loop invariants,

More information

A Logical View of Effects

A Logical View of Effects A Logical View of Effects Sungwoo Park and Robert Harper Computer Science Department Carnegie Mellon University {gla,rwh}@cs.cmu.edu Abstract Despite their invaluable contribution to the programming language

More information

Objects as Session-Typed Processes

Objects as Session-Typed Processes Objects as Session-Typed Processes Stephanie Balzer and Frank Pfenning Computer Science Department, Carnegie Mellon University AGERE! 2015 The essence of object-orientation 2 The essence of object-orientation

More information

A NEW PROOF-ASSISTANT THAT REVISITS HOMOTOPY TYPE THEORY THE THEORETICAL FOUNDATIONS OF COQ USING NICOLAS TABAREAU

A NEW PROOF-ASSISTANT THAT REVISITS HOMOTOPY TYPE THEORY THE THEORETICAL FOUNDATIONS OF COQ USING NICOLAS TABAREAU COQHOTT A NEW PROOF-ASSISTANT THAT REVISITS THE THEORETICAL FOUNDATIONS OF COQ USING HOMOTOPY TYPE THEORY NICOLAS TABAREAU The CoqHoTT project Design and implement a brand-new proof assistant by revisiting

More information

Note that in this definition, n + m denotes the syntactic expression with three symbols n, +, and m, not to the number that is the sum of n and m.

Note that in this definition, n + m denotes the syntactic expression with three symbols n, +, and m, not to the number that is the sum of n and m. CS 6110 S18 Lecture 8 Structural Operational Semantics and IMP Today we introduce a very simple imperative language, IMP, along with two systems of rules for evaluation called small-step and big-step semantics.

More information

6.001 Notes: Section 4.1

6.001 Notes: Section 4.1 6.001 Notes: Section 4.1 Slide 4.1.1 In this lecture, we are going to take a careful look at the kinds of procedures we can build. We will first go back to look very carefully at the substitution model,

More information

Part III. Chapter 15: Subtyping

Part III. Chapter 15: Subtyping Part III Chapter 15: Subtyping Subsumption Subtype relation Properties of subtyping and typing Subtyping and other features Intersection and union types Subtyping Motivation With the usual typing rule

More information

1.3. Conditional expressions To express case distinctions like

1.3. Conditional expressions To express case distinctions like Introduction Much of the theory developed in the underlying course Logic II can be implemented in a proof assistant. In the present setting this is interesting, since we can then machine extract from a

More information

CS4215 Programming Language Implementation. Martin Henz

CS4215 Programming Language Implementation. Martin Henz CS4215 Programming Language Implementation Martin Henz Thursday 15 March, 2012 2 Chapter 11 impl: A Simple Imperative Language 11.1 Introduction So far, we considered only languages, in which an identifier

More information

The three faces of homotopy type theory. Type theory and category theory. Minicourse plan. Typing judgments. Michael Shulman.

The three faces of homotopy type theory. Type theory and category theory. Minicourse plan. Typing judgments. Michael Shulman. The three faces of homotopy type theory Type theory and category theory Michael Shulman 1 A programming language. 2 A foundation for mathematics based on homotopy theory. 3 A calculus for (, 1)-category

More information

Part III Chapter 15: Subtyping

Part III Chapter 15: Subtyping Part III Chapter 15: Subtyping Subsumption Subtype relation Properties of subtyping and typing Subtyping and other features Intersection and union types Subtyping Motivation With the usual typing rule

More information

Formal Systems and their Applications

Formal Systems and their Applications Formal Systems and their Applications Dave Clarke (Dave.Clarke@cs.kuleuven.be) Acknowledgment: these slides are based in part on slides from Benjamin Pierce and Frank Piessens 1 Course Overview Introduction

More information

Introduction to Homotopy Type Theory

Introduction to Homotopy Type Theory Introduction to Homotopy Type Theory Lecture notes for a course at EWSCS 2017 Thorsten Altenkirch March 5, 2017 1 What is this course about? To explain what Homotopy Type Theory is, I will first talk about

More information

Binary Decision Diagrams

Binary Decision Diagrams Logic and roof Hilary 2016 James Worrell Binary Decision Diagrams A propositional formula is determined up to logical equivalence by its truth table. If the formula has n variables then its truth table

More information

6.001 Notes: Section 8.1

6.001 Notes: Section 8.1 6.001 Notes: Section 8.1 Slide 8.1.1 In this lecture we are going to introduce a new data type, specifically to deal with symbols. This may sound a bit odd, but if you step back, you may realize that everything

More information

COS 320. Compiling Techniques

COS 320. Compiling Techniques Topic 5: Types COS 320 Compiling Techniques Princeton University Spring 2016 Lennart Beringer 1 Types: potential benefits (I) 2 For programmers: help to eliminate common programming mistakes, particularly

More information

Acknowledgements. Outline

Acknowledgements. Outline Acknowledgements Heuristic Search for Planning Sheila McIlraith University of Toronto Fall 2010 Many of the slides used in today s lecture are modifications of slides developed by Malte Helmert, Bernhard

More information

Tradeoffs. CSE 505: Programming Languages. Lecture 15 Subtyping. Where shall we add useful completeness? Where shall we add completeness?

Tradeoffs. CSE 505: Programming Languages. Lecture 15 Subtyping. Where shall we add useful completeness? Where shall we add completeness? Tradeoffs CSE 505: Programming Languages Lecture 15 Subtyping Zach Tatlock Autumn 2017 Desirable type system properties (desiderata): soundness - exclude all programs that get stuck completeness - include

More information

A Modal Analysis of Staged Computation Rowan Davies and Frank Pfenning Carnegie Mellon University We show that a type system based on the intuitionist

A Modal Analysis of Staged Computation Rowan Davies and Frank Pfenning Carnegie Mellon University We show that a type system based on the intuitionist A Modal Analysis of Staged Computation Rowan Davies and Frank Pfenning Carnegie Mellon University We show that a type system based on the intuitionistic modal logic S4 provides an expressive framework

More information

Multiway Blockwise In-place Merging

Multiway Blockwise In-place Merging Multiway Blockwise In-place Merging Viliam Geffert and Jozef Gajdoš Institute of Computer Science, P.J.Šafárik University, Faculty of Science Jesenná 5, 041 54 Košice, Slovak Republic viliam.geffert@upjs.sk,

More information

Type Safety. Java and ML are type safe, or strongly typed, languages. C and C++ are often described as weakly typed languages.

Type Safety. Java and ML are type safe, or strongly typed, languages. C and C++ are often described as weakly typed languages. Java and ML are type safe, or strongly typed, languages. CMPSCI 630: Programming Languages Spring 2009 (with thanks to Robert Harper) C and C++ are often described as weakly typed languages. What does

More information

Bootcamp. Christoph Thiele. Summer An example of a primitive universe

Bootcamp. Christoph Thiele. Summer An example of a primitive universe Bootcamp Christoph Thiele Summer 2012 0.1 An example of a primitive universe A primitive universe consists of primitive objects and primitive sets. This allows to form primitive statements as to which

More information

Joint Entity Resolution

Joint Entity Resolution Joint Entity Resolution Steven Euijong Whang, Hector Garcia-Molina Computer Science Department, Stanford University 353 Serra Mall, Stanford, CA 94305, USA {swhang, hector}@cs.stanford.edu No Institute

More information

Formal Syntax and Semantics of Programming Languages

Formal Syntax and Semantics of Programming Languages Formal Syntax and Semantics of Programming Languages Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson http://www.daimi.au.dk/~bra8130/wiley_book/wiley.html axioms

More information

CIS 1.5 Course Objectives. a. Understand the concept of a program (i.e., a computer following a series of instructions)

CIS 1.5 Course Objectives. a. Understand the concept of a program (i.e., a computer following a series of instructions) By the end of this course, students should CIS 1.5 Course Objectives a. Understand the concept of a program (i.e., a computer following a series of instructions) b. Understand the concept of a variable

More information

A Modality for Recursion

A Modality for Recursion A Modality for Recursion (Technical Report) March 31, 2001 Hiroshi Nakano Ryukoku University, Japan nakano@mathryukokuacjp Abstract We propose a modal logic that enables us to handle self-referential formulae,

More information

7. Introduction to Denotational Semantics. Oscar Nierstrasz

7. Introduction to Denotational Semantics. Oscar Nierstrasz 7. Introduction to Denotational Semantics Oscar Nierstrasz Roadmap > Syntax and Semantics > Semantics of Expressions > Semantics of Assignment > Other Issues References > D. A. Schmidt, Denotational Semantics,

More information

The Substitution Model. Nate Foster Spring 2018

The Substitution Model. Nate Foster Spring 2018 The Substitution Model Nate Foster Spring 2018 Review Previously in 3110: simple interpreter for expression language abstract syntax tree (AST) evaluation based on single steps parser and lexer (in lab)

More information

From IMP to Java. Andreas Lochbihler. parts based on work by Gerwin Klein and Tobias Nipkow ETH Zurich

From IMP to Java. Andreas Lochbihler. parts based on work by Gerwin Klein and Tobias Nipkow ETH Zurich From IMP to Java Andreas Lochbihler ETH Zurich parts based on work by Gerwin Klein and Tobias Nipkow 2015-07-14 1 Subtyping 2 Objects and Inheritance 3 Multithreading 1 Subtyping 2 Objects and Inheritance

More information

Symmetry in Type Theory

Symmetry in Type Theory Google May 29th, 2012 What is Symmetry? Definition Symmetry: Two or more things that initially look distinct, may actually be instances of a more general underlying principle. Why do we care? Simplicity.

More information

On Meaning Preservation of a Calculus of Records

On Meaning Preservation of a Calculus of Records On Meaning Preservation of a Calculus of Records Emily Christiansen and Elena Machkasova Computer Science Discipline University of Minnesota, Morris Morris, MN 56267 chri1101, elenam@morris.umn.edu Abstract

More information

3.7 Denotational Semantics

3.7 Denotational Semantics 3.7 Denotational Semantics Denotational semantics, also known as fixed-point semantics, associates to each programming language construct a well-defined and rigorously understood mathematical object. These

More information

Heuristic Search for Planning

Heuristic Search for Planning Heuristic Search for Planning Sheila McIlraith University of Toronto Fall 2010 S. McIlraith Heuristic Search for Planning 1 / 50 Acknowledgements Many of the slides used in today s lecture are modifications

More information

Lecture 15 CIS 341: COMPILERS

Lecture 15 CIS 341: COMPILERS Lecture 15 CIS 341: COMPILERS Announcements HW4: OAT v. 1.0 Parsing & basic code generation Due: March 28 th No lecture on Thursday, March 22 Dr. Z will be away Zdancewic CIS 341: Compilers 2 Adding Integers

More information

Types, Universes and Everything

Types, Universes and Everything Types, Universes and Everything Andres Löh Dept. of Information and Computing Sciences, Utrecht University P.O. Box 80.089, 3508 TB Utrecht, The Netherlands Web pages: http://www.cs.uu.nl/wiki/center May

More information

Part VI. Imperative Functional Programming

Part VI. Imperative Functional Programming Part VI Imperative Functional Programming Chapter 14 Mutable Storage MinML is said to be a pure language because the execution model consists entirely of evaluating an expression for its value. ML is

More information

Mathematically Rigorous Software Design Review of mathematical prerequisites

Mathematically Rigorous Software Design Review of mathematical prerequisites Mathematically Rigorous Software Design 2002 September 27 Part 1: Boolean algebra 1. Define the Boolean functions and, or, not, implication ( ), equivalence ( ) and equals (=) by truth tables. 2. In an

More information

CITS3211 FUNCTIONAL PROGRAMMING. 14. Graph reduction

CITS3211 FUNCTIONAL PROGRAMMING. 14. Graph reduction CITS3211 FUNCTIONAL PROGRAMMING 14. Graph reduction Summary: This lecture discusses graph reduction, which is the basis of the most common compilation technique for lazy functional languages. CITS3211

More information

Mutable References. Chapter 1

Mutable References. Chapter 1 Chapter 1 Mutable References In the (typed or untyped) λ-calculus, or in pure functional languages, a variable is immutable in that once bound to a value as the result of a substitution, its contents never

More information

Functional Programming with Names and Necessity

Functional Programming with Names and Necessity Functional Programming with Names and Necessity Aleksandar Nanevski June 2004 CMU-CS-04-151 School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 Submitted in partial fulfillment of

More information

Computing Fundamentals 2 Introduction to CafeOBJ

Computing Fundamentals 2 Introduction to CafeOBJ Computing Fundamentals 2 Introduction to CafeOBJ Lecturer: Patrick Browne Lecture Room: K408 Lab Room: A308 Based on work by: Nakamura Masaki, João Pascoal Faria, Prof. Heinrich Hußmann. See notes on slides

More information

Inference rule for Induction

Inference rule for Induction Inference rule for Induction Let P( ) be a predicate with domain the positive integers BASE CASE INDUCTIVE STEP INDUCTIVE Step: Usually a direct proof Assume P(x) for arbitrary x (Inductive Hypothesis),

More information

CONVENTIONAL EXECUTABLE SEMANTICS. Grigore Rosu CS522 Programming Language Semantics

CONVENTIONAL EXECUTABLE SEMANTICS. Grigore Rosu CS522 Programming Language Semantics CONVENTIONAL EXECUTABLE SEMANTICS Grigore Rosu CS522 Programming Language Semantics Conventional Semantic Approaches A language designer should understand the existing design approaches, techniques and

More information

Lecture 3 Notes Arrays

Lecture 3 Notes Arrays Lecture 3 Notes Arrays 15-122: Principles of Imperative Computation (Summer 1 2015) Frank Pfenning, André Platzer 1 Introduction So far we have seen how to process primitive data like integers in imperative

More information

Dependent Types and Irrelevance

Dependent Types and Irrelevance Dependent Types and Irrelevance Christoph-Simon Senjak Technische Universität München Institut für Informatik Boltzmannstraße 3 85748 Garching PUMA Workshop September 2012 Dependent Types Dependent Types

More information

Topic 3: Propositions as types

Topic 3: Propositions as types Topic 3: Propositions as types May 18, 2014 Propositions as types We have seen that the main mathematical objects in a type theory are types. But remember that in conventional foundations, as based on

More information

Formal Semantics. Prof. Clarkson Fall Today s music: Down to Earth by Peter Gabriel from the WALL-E soundtrack

Formal Semantics. Prof. Clarkson Fall Today s music: Down to Earth by Peter Gabriel from the WALL-E soundtrack Formal Semantics Prof. Clarkson Fall 2015 Today s music: Down to Earth by Peter Gabriel from the WALL-E soundtrack Review Previously in 3110: simple interpreter for expression language: abstract syntax

More information

CONVENTIONAL EXECUTABLE SEMANTICS. Grigore Rosu CS422 Programming Language Semantics

CONVENTIONAL EXECUTABLE SEMANTICS. Grigore Rosu CS422 Programming Language Semantics CONVENTIONAL EXECUTABLE SEMANTICS Grigore Rosu CS422 Programming Language Semantics Conventional Semantic Approaches A language designer should understand the existing design approaches, techniques and

More information

Beluga: A Framework for Programming and Reasoning with Deductive Systems (System Description)

Beluga: A Framework for Programming and Reasoning with Deductive Systems (System Description) Beluga: A Framework for Programming and Reasoning with Deductive Systems (System Description) Brigitte Pientka and Joshua Dunfield McGill University, Montréal, Canada {bpientka,joshua}@cs.mcgill.ca Abstract.

More information

CMSC 330: Organization of Programming Languages

CMSC 330: Organization of Programming Languages CMSC 330: Organization of Programming Languages Operational Semantics CMSC 330 Summer 2018 1 Formal Semantics of a Prog. Lang. Mathematical description of the meaning of programs written in that language

More information

CSC 501 Semantics of Programming Languages

CSC 501 Semantics of Programming Languages CSC 501 Semantics of Programming Languages Subtitle: An Introduction to Formal Methods. Instructor: Dr. Lutz Hamel Email: hamel@cs.uri.edu Office: Tyler, Rm 251 Books There are no required books in this

More information

Type Systems Winter Semester 2006

Type Systems Winter Semester 2006 Type Systems Winter Semester 2006 Week 4 November 8 November 15, 2006 - version 1.1 The Lambda Calculus The lambda-calculus If our previous language of arithmetic expressions was the simplest nontrivial

More information

Verifying Program Invariants with Refinement Types

Verifying Program Invariants with Refinement Types Verifying Program Invariants with Refinement Types Rowan Davies and Frank Pfenning Carnegie Mellon University Princeton and Yale Colloquium Talks February, 2001 Acknowledgments: Robert Harper 1 Overview

More information

Comp 311: Sample Midterm Examination

Comp 311: Sample Midterm Examination Comp 311: Sample Midterm Examination October 29, 2007 Name: Id #: Instructions 1. The examination is closed book. If you forget the name for a Scheme operation, make up a name for it and write a brief

More information

Subtyping and Objects

Subtyping and Objects Subtyping and Objects Massimo Merro 20 November 2017 Massimo Merro Data and Mutable Store 1 / 22 Polymorphism So far, our type systems are very rigid: there is little support to code reuse. Polymorphism

More information

Lecture Notes on Program Equivalence

Lecture Notes on Program Equivalence Lecture Notes on Program Equivalence 15-312: Foundations of Programming Languages Frank Pfenning Lecture 24 November 30, 2004 When are two programs equal? Without much reflection one might say that two

More information

CSE 373 Spring 2010: Midterm #1 (closed book, closed notes, NO calculators allowed)

CSE 373 Spring 2010: Midterm #1 (closed book, closed notes, NO calculators allowed) Name: Email address: CSE 373 Spring 2010: Midterm #1 (closed book, closed notes, NO calculators allowed) Instructions: Read the directions for each question carefully before answering. We may give partial

More information

4.5 Pure Linear Functional Programming

4.5 Pure Linear Functional Programming 4.5 Pure Linear Functional Programming 99 4.5 Pure Linear Functional Programming The linear λ-calculus developed in the preceding sections can serve as the basis for a programming language. The step from

More information

DATABASE THEORY. Lecture 11: Introduction to Datalog. TU Dresden, 12th June Markus Krötzsch Knowledge-Based Systems

DATABASE THEORY. Lecture 11: Introduction to Datalog. TU Dresden, 12th June Markus Krötzsch Knowledge-Based Systems DATABASE THEORY Lecture 11: Introduction to Datalog Markus Krötzsch Knowledge-Based Systems TU Dresden, 12th June 2018 Announcement All lectures and the exercise on 19 June 2018 will be in room APB 1004

More information

Propositional Logic. Part I

Propositional Logic. Part I Part I Propositional Logic 1 Classical Logic and the Material Conditional 1.1 Introduction 1.1.1 The first purpose of this chapter is to review classical propositional logic, including semantic tableaux.

More information

Last class. CS Principles of Programming Languages. Introduction. Outline

Last class. CS Principles of Programming Languages. Introduction. Outline Last class CS6848 - Principles of Programming Languages Principles of Programming Languages V. Krishna Nandivada IIT Madras Interpreters A Environment B Cells C Closures D Recursive environments E Interpreting

More information

CS152: Programming Languages. Lecture 2 Syntax. Dan Grossman Spring 2011

CS152: Programming Languages. Lecture 2 Syntax. Dan Grossman Spring 2011 CS152: Programming Languages Lecture 2 Syntax Dan Grossman Spring 2011 Finally, some formal PL content For our first formal language, let s leave out functions, objects, records, threads, exceptions,...

More information

Topic 1: What is HoTT and why?

Topic 1: What is HoTT and why? Topic 1: What is HoTT and why? May 5, 2014 Introduction Homotopy type theory (HoTT) is a newly emerging field of mathematics which is currently being developed as a foundation of mathematics which is in

More information

COSC252: Programming Languages: Semantic Specification. Jeremy Bolton, PhD Adjunct Professor

COSC252: Programming Languages: Semantic Specification. Jeremy Bolton, PhD Adjunct Professor COSC252: Programming Languages: Semantic Specification Jeremy Bolton, PhD Adjunct Professor Outline I. What happens after syntactic analysis (parsing)? II. Attribute Grammars: bridging the gap III. Semantic

More information

CS558 Programming Languages

CS558 Programming Languages CS558 Programming Languages Fall 2016 Lecture 3a Andrew Tolmach Portland State University 1994-2016 Formal Semantics Goal: rigorous and unambiguous definition in terms of a wellunderstood formalism (e.g.

More information