CMSC 330: Organization of Programming Languages. Operational Semantics

Similar documents
Tail Calls. CMSC 330: Organization of Programming Languages. Tail Recursion. Tail Recursion (cont d) Names and Binding. Tail Recursion (cont d)

CMSC 330: Organization of Programming Languages. Formal Semantics of a Prog. Lang. Specifying Syntax, Semantics

CMSC 330: Organization of Programming Languages

Chapter 3 (part 3) Describing Syntax and Semantics

CMSC 330: Organization of Programming Languages. Lambda Calculus

The Substitution Model

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

Programming Languages Third Edition

CMSC 330: Organization of Programming Languages

Lecture 15 CIS 341: COMPILERS

CMSC 330: Organization of Programming Languages. Lambda Calculus

Comp 411 Principles of Programming Languages Lecture 7 Meta-interpreters. Corky Cartwright January 26, 2018

Tuples. CMSC 330: Organization of Programming Languages. Examples With Tuples. Another Example

CMSC 330: Organization of Programming Languages

The Substitution Model. Nate Foster Spring 2018

Programming Language Features. CMSC 330: Organization of Programming Languages. Turing Completeness. Turing Machine.

CMSC 330: Organization of Programming Languages

Semantic Analysis. Lecture 9. February 7, 2018

(Provisional) Lecture 22: Rackette Overview, Binary Tree Analysis 10:00 AM, Oct 27, 2017

Goals: Define the syntax of a simple imperative language Define a semantics using natural deduction 1

Lecture 3: Recursion; Structural Induction

CMSC 330: Organization of Programming Languages

Topics Covered Thus Far. CMSC 330: Organization of Programming Languages. Language Features Covered Thus Far. Programming Languages Revisited

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

In Our Last Exciting Episode

CSCE 314 TAMU Fall CSCE 314: Programming Languages Dr. Flemming Andersen. Haskell Functions

Formal Systems and their Applications

CSE505, Fall 2012, Midterm Examination October 30, 2012

CMSC330. Objects, Functional Programming, and lambda calculus

Shell CSCE 314 TAMU. Haskell Functions

Midterm 1. CMSC 430 Introduction to Compilers Spring Instructions Total 100. Name: March 14, 2012

Formal Semantics. Chapter Twenty-Three Modern Programming Languages, 2nd ed. 1

3.7 Denotational Semantics

Organization of Programming Languages CS3200/5200N. Lecture 11

CMSC 330, Fall 2018 Midterm 2

The Environment Model. Nate Foster Spring 2018

Summer 2017 Discussion 10: July 25, Introduction. 2 Primitives and Define

CSCE 314 Programming Languages. Type System

Intro. Scheme Basics. scm> 5 5. scm>

CSCI B522 Lecture 11 Naming and Scope 8 Oct, 2009

The Environment Model

Contents. Chapter 1 SPECIFYING SYNTAX 1

7. Introduction to Denotational Semantics. Oscar Nierstrasz

Simply-Typed Lambda Calculus

Lecture 2: Big-Step Semantics

CS 11 Haskell track: lecture 1

CIS 500 Software Foundations Fall September 25

CMSC 336: Type Systems for Programming Languages Lecture 5: Simply Typed Lambda Calculus Acar & Ahmed January 24, 2008

CSCC24 Functional Programming Scheme Part 2

Type Checking. Outline. General properties of type systems. Types in programming languages. Notation for type rules.

Outline. General properties of type systems. Types in programming languages. Notation for type rules. Common type rules. Logical rules of inference

An Introduction to Functions

Introduction to Scheme

Closures. Mooly Sagiv. Michael Clarkson, Cornell CS 3110 Data Structures and Functional Programming

CSCI-GA Scripting Languages

Handout 10: Imperative programs and the Lambda Calculus

CMSC330 Spring 2012 Final Exam Solutions

Handout 9: Imperative Programs and State

Operational Semantics. One-Slide Summary. Lecture Outline

Functional Programming. Pure Functional Programming

CS 4110 Programming Languages & Logics. Lecture 17 Programming in the λ-calculus

n n Try tutorial on front page to get started! n spring13/ n Stack Overflow!

n Closed book n You are allowed 5 cheat pages n Practice problems available in Course Materials n Check grades in Rainbow grades

Programming Languages and Compilers (CS 421)

CMSC 330: Organization of Programming Languages

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.

Functional Programming. Big Picture. Design of Programming Languages

SCHEME 8. 1 Introduction. 2 Primitives COMPUTER SCIENCE 61A. March 23, 2017

CVO103: Programming Languages. Lecture 5 Design and Implementation of PLs (1) Expressions

Parsing. Zhenjiang Hu. May 31, June 7, June 14, All Right Reserved. National Institute of Informatics

Introductory logic and sets for Computer scientists

Closures. Mooly Sagiv. Michael Clarkson, Cornell CS 3110 Data Structures and Functional Programming

Propositional Calculus: Boolean Functions and Expressions. CS 270: Mathematical Foundations of Computer Science Jeremy Johnson

Program Abstractions, Language Paradigms. CS152. Chris Pollett. Aug. 27, 2008.

Harvard School of Engineering and Applied Sciences CS 152: Programming Languages. Lambda calculus

Metaprogramming assignment 3

CMSC330 Spring 2016 Midterm #2 9:30am/12:30pm/3:30pm

Project 5 Due 11:59:59pm Tuesday, April 25, 2017

Project 5 Due 11:59:59pm Tue, Dec 11, 2012

CS 415 Midterm Exam Spring 2002

The Lambda Calculus. 27 September. Fall Software Foundations CIS 500. The lambda-calculus. Announcements

CMSC 330, Fall 2018 Midterm 2

Boolean expressions. Elements of Programming Languages. Conditionals. What use is this?

Project 5 Due 11:59:59pm Wed, Nov 25, 2015 (no late submissions)

Programming Languages 3. Definition and Proof by Induction

Functional Programming. Pure Functional Languages

Lecture Outline. COOL operational semantics. Operational Semantics of Cool. Motivation. Lecture 13. Notation. The rules. Evaluation Rules So Far

Project 2: Scheme Interpreter

Functional Programming. Pure Functional Languages

Semantics of programming languages

CS152: Programming Languages. Lecture 7 Lambda Calculus. Dan Grossman Spring 2011

Compiler Theory. (Semantic Analysis and Run-Time Environments)

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

Concepts of programming languages

Introduction to Parsing. Lecture 8

CMSC330 Fall 2016 Midterm #2 2:00pm/3:30pm

Formal Semantics of Programming Languages

Topics Covered Thus Far CMSC 330: Organization of Programming Languages

1 Lexical Considerations

Defining Languages GMU

Transcription:

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 to finish Parts 1 & 2 ASAP and begin working on Part 3 There is one important function from Part 2 that you will need in Part 3: lookup CMSC 330 2

Review of CMSC 330 Syntax Regular expressions Finite automata Context-free grammars Semantics Operational semantics Lambda calculus Implementation Concurrency Generics Argument passing Scoping Exceptions CMSC 330 3

CMSC 330

CMSC 330

Operational Semantics There are several different kinds of semantics Denotational: A program is a mathematical function Axiomatic: Develop a logical proof of a program Give predicates that hold when a program (or part) is executed We will briefly look at operational semantics A program is defined by how you execute it on a mathematical model of a machine We will look at a subset of OCaml as an example CMSC 330 6

Evaluation We re going to define a relation E v This means expression E evaluates to v Sometimes simply read as E goes to v We ll use grammars to describe each of these One to describe program abstract syntax trees E One to describe result values v CMSC 330 7

OCaml Programs E ::= x n true false if E then E else E fun x = E E E x stands for any identifier n stands for any integer true and false stand for the two boolean values Using = in fun instead of -> to avoid confusion CMSC 330 8

Values v ::= n true false n is an integer (not a string corresp. to an integer) Same idea for true, false Important: Be sure to understand the difference between program text S and mathematical objects v. E.g., the text 3 evaluates to the mathematical number 3 To help, we ll use different colors and italics This is usually not done, and it s up to the reader to remember which is which CMSC 330 9

Grammars for Trees We re just using grammars to describe trees E ::= x n true false if E then E else E fun x = E E E v ::= n true false type expr = Id of string Num of int Bool of bool If of expr * expr * expr Fun of string * expr App of expr * expr Given a program, we have seen how to convert it to an AST(e.g., recursive descent parsing) type value = VNum of int VBool of bool Goal: For any expr, we want an operational rule describing how to obtain a value that represents its execution CMSC 330 10

Operational Semantics Rules n n true true false false Each basic entity evaluates to the corresponding value CMSC 330 11

Operational Semantics Rules (cont d) How about built-in functions? + n m n + m We re applying the + function Ignore currying for the moment, and pretend we have multiargument functions On the right-hand side, we re computing the mathematical sum; the left-hand side is source code But what about + (+ 3 4) 5? We need recursion CMSC 330 12

Recursive Rules To evaluate + E 1 E 2, we need to evaluate E 1, then evaluate E 2, then add the results This is call-by-value E 1 n E 2 m + E 1 E 2 n + m This is a natural deduction style rule It says that if the hypotheses above the line hold, then the conclusion below the line holds i.e., if E 1 executes to value n and if E 2 executes to value m, then + E 1 E 2 executes to value n+m CMSC 330 13

Trees of Semantic Rules When we apply rules to an expression, we actually get a tree Corresponds to the recursive evaluation procedure For example: + (+ 3 4 ) 5 3 3 4 4 (+ 3 4) 7 5 5 + ( + 3 4) 5 12 CMSC 330 14

Rules for If E 1 true E 2 v if E 1 then E 2 else E 3 v E 1 false E 3 v if E 1 then E 2 else E 3 v Examples if false then 3 else 4 4 if true then 3 else 4 3 Notice that only one branch is evaluated CMSC 330 15

Rules for Identifiers Let s assume for now that the only identifiers are parameter names Ex. (fun x = + x 3) 4 When we see x in the body, we need to look it up So we need to keep some sort of environment This will be a map from identifiers to values CMSC 330 16

Semantics with Environments Extend rules to the form A E v Means in environment A, the program text E evaluates to v Notation: We write for the empty environment We write A(x) for the value that x maps to in A We write A, x v for the same environment as A, except x is now v might be a new (replacement) mapping for x We write A, A' for the environment with the bindings of A' added to and overriding the bindings of A CMSC 330 17

Rules for Identifiers and Application A x A(x) no hypothesis means in all cases A E 2 v A, x v E 1 v' A ( (fun x = E 1 ) E 2 ) v' To evaluate a user-defined function applied to an argument: Evaluate the argument (call-by-value) Evaluate the function body in an environment in which the formal parameter is bound to the actual argument Return the result CMSC 330 18

Operational Semantics Rules SInt A n n SVar x v A A x v SAdd A e 1 n A e 2 m A + e 1 e 2 n + m SFun A e 2 v A, x v e 1 v' A (fun x = e 1 ) e 2 v' CMSC 330 19

Example: (fun x = + x 3) 4? SInt SVar x 4 x 4 x 4 3 3 4 4 x 4 + x 3 7 (fun x = + x 3) 4 7 SFun SAdd SInt CMSC 330 20

Exercises 42 + 8 9 A + 3 m A: m 5 (fun x = x) 7 (fun b = (fun a = a + b) 8) 9 CMSC 330 21

Error Cases Recall the rule for built-in addition: E 1 n E 2 m Because we wrote n, m in the hypothesis, we mean that they must be integers But what if E 1 and E 2 aren t integers? E.g., what if we write + false true? It can be parsed, but we can t execute it We will have no rule that covers such a case Runtime error! + E 1 E 2 n + m CMSC 330 22

Why Did We Do This? Operational semantics are useful for Describing languages Not just OCaml! It s pretty hard to describe a big language like C or Java, but we can at least describe the core components of the language Giving a precise specification of how they work Look in any language standard they tend to be vague in many places and leave things undefined Reasoning about programs We can actually prove that programs do something or don t do something, because we have a precise definition of how they work CMSC 330 23

Why Did We REALLY Do This? P4, Part 3 is all about operational semantics You are implementing an interpreter for the Rube language, which means understanding and implementing its operational semantics AST definition ( expr ) on page 2 Value definition ( value ) on page 5 Rule definitions on page 6 Other concepts: Classes and methods (page 2) Heaps and environments (page 5) Built-in methods (page 8) CMSC 330 24

Conclusion READ THE SPEC Print it Study it Ask questions about it Focus on the definitions Pay attention to details For instance: H H H 0 H 1 (etc.) The better you understand the project description, the easier you will find Part 3 to be CMSC 330 25

Aside: Nested Functions All this works for cases of nested functions...as long as they are fully applied But what about the true higher-order cases? Passing functions as arguments, and returning functions as results We need closures to handle this case...and a closure was just a function and an environment We already have notation around for writing both parts CMSC 330 26

Closures Formally, we add closures (A, λx.e) to values A is the environment in which the closure was created x is the parameter name E is the source code for the body λx will be discussed next time. Means a binding of x in E. v ::= n true false [] v::v (A, λx.e) CMSC 330 27

Revised Rule for Lambda SLambda A fun x = E (A, λx.e) To evaluate a function definition, create a closure when the function is created Notice that we don t look inside the function body CMSC 330 28

Revised Rule for Application SApp A E 1 (A', λx.e) A E 2 v A, A', x v E v' A (E 1 E 2 ) v' To apply something to an argument: Evaluate it to produce a closure Evaluate the argument (call-by-value) Evaluate the body of the closure, in The current environment, extended with the closure s environment, extended with the binding for the parameter CMSC 330 29

Exercise (fun x = + x 3) 7 CMSC 330 30

Example (fun x = (fun y = + x y)) (, λx.(fun y = + x y)) x 3 (fun y = + x y) 3 3 (x 3, λy.(+ x y)) (fun x = (fun y = + x y)) 3 (x 3, λy.(+ x y)) Let <previous> = (fun x = (fun y = + x y)) 3 CMSC 330 31

Example (cont d) <previous> (x 3, λy.(+ x y)) 4 4 x 3,y 4 (+ x y) 7 ( <previous> 4 ) 7 CMSC 330 32