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

Similar documents
CMSC 330: Organization of Programming Languages

CMSC 330: Organization of Programming Languages. Operational Semantics

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

Programming Languages Third Edition

Chapter 3 (part 3) Describing Syntax and Semantics

Lecture 15 CIS 341: COMPILERS

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

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

CMSC 330: Organization of Programming Languages

Principles of Programming Languages

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

Formal Semantics of Programming Languages

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

Formal Semantics of Programming Languages

Static semantics. Lecture 3-6: Semantics. Attribute grammars (2) Attribute grammars. Attribute grammars example. Dynamic semantics

CMSC 330: Organization of Programming Languages. Lambda Calculus

Flang typechecker Due: February 27, 2015

1 Introduction. 3 Syntax

Syntax vs. semantics. Detour: Natural deduction. Syntax vs. semantics (cont d) Syntax = grammatical structure Semantics = underlying meaning

Lecture 2: Big-Step Semantics

CMSC 330: Organization of Programming Languages. OCaml Imperative Programming

The Substitution Model

A simple syntax-directed

Homework 3 COSE212, Fall 2018

Intro to semantics; Small-step semantics Lecture 1 Tuesday, January 29, 2013

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

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

Chapter 3. Describing Syntax and Semantics

Basic concepts. Chapter Toplevel loop

Formal Systems and their Applications

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

A Simple Syntax-Directed Translator

CMSC 330: Organization of Programming Languages. Lambda Calculus

Operational Semantics. One-Slide Summary. Lecture Outline

Chapter 3. Describing Syntax and Semantics ISBN

Chapter 3. Describing Syntax and Semantics

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

Outline. What is semantics? Denotational semantics. Semantics of naming. What is semantics? 2 / 21

Chapter 3. Semantics. Topics. Introduction. Introduction. Introduction. Introduction

Lectures 20, 21: Axiomatic Semantics

Types. Type checking. Why Do We Need Type Systems? Types and Operations. What is a type? Consensus

CMSC 330: Organization of Programming Languages. OCaml Imperative Programming

CMSC330. Objects, Functional Programming, and lambda calculus

CMSC 330: Organization of Programming Languages

Application: Programming Language Semantics

CS 6110 S11 Lecture 25 Typed λ-calculus 6 April 2011

CSCE 314 Programming Languages. Type System

Programming Languages Fall 2013

CSE 413 Languages & Implementation. Hal Perkins Winter 2019 Structs, Implementing Languages (credits: Dan Grossman, CSE 341)

7. Introduction to Denotational Semantics. Oscar Nierstrasz

Semantics. There is no single widely acceptable notation or formalism for describing semantics Operational Semantics

Contents. Chapter 1 SPECIFYING SYNTAX 1

Outline. Introduction Concepts and terminology The case for static typing. Implementing a static type system Basic typing relations Adding context

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

CMSC 330: Organization of Programming Languages

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

Syntax/semantics. Program <> program execution Compiler/interpreter Syntax Grammars Syntax diagrams Automata/State Machines Scanning/Parsing

CMSC 330: Organization of Programming Languages

Operational Semantics 1 / 13

COS 320. Compiling Techniques

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

The Substitution Model. Nate Foster Spring 2018

Crafting a Compiler with C (II) Compiler V. S. Interpreter

In Our Last Exciting Episode

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

Chapter 3. Semantics. Topics. Introduction. Introduction. Introduction. Introduction

Lecture 3: Recursion; Structural Induction

Defining Languages GMU

Chapter 3: CONTEXT-FREE GRAMMARS AND PARSING Part 1

Semantic Analysis. Lecture 9. February 7, 2018

Operational Semantics of Cool

Context-Free Grammars

Scope and Introduction to Functional Languages. Review and Finish Scoping. Announcements. Assignment 3 due Thu at 11:55pm. Website has SML resources

Programming Languages Third Edition. Chapter 7 Basic Semantics

CS 242. Fundamentals. Reading: See last slide

axiomatic semantics involving logical rules for deriving relations between preconditions and postconditions.

3.7 Denotational Semantics

Functional Programming. Pure Functional Programming

Modules, Structs, Hashes, and Operational Semantics

Programming Languages and Compilers (CS 421)

CS152 Programming Language Paradigms Prof. Tom Austin, Fall Syntax & Semantics, and Language Design Criteria

Topics Covered Thus Far CMSC 330: Organization of Programming Languages

Lecture Note: Types. 1 Introduction 2. 2 Simple Types 3. 3 Type Soundness 6. 4 Recursive Types Subtyping 17

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

Hoare Logic: Proving Programs Correct

Specifying Syntax. An English Grammar. Components of a Grammar. Language Specification. Types of Grammars. 1. Terminal symbols or terminals, Σ

CSE 401 Midterm Exam Sample Solution 2/11/15

Chapter 3. Describing Syntax and Semantics ISBN

Chapter 3. Syntax - the form or structure of the expressions, statements, and program units

CSE341: Programming Languages Lecture 17 Implementing Languages Including Closures. Dan Grossman Autumn 2018

MIDTERM EXAMINATION - CS130 - Spring 2005

RYERSON POLYTECHNIC UNIVERSITY DEPARTMENT OF MATH, PHYSICS, AND COMPUTER SCIENCE CPS 710 FINAL EXAM FALL 96 INSTRUCTIONS

Metaprogramming assignment 3

CIS 341 Midterm February 28, Name (printed): Pennkey (login id): SOLUTIONS

Formal Semantics of Programming Languages

Begin at the beginning

Introduction to the λ-calculus

CSE-321: Assignment 8 (100 points)

Lecture 2: SML Basics

CMSC 330, Fall 2013, Practice Problem 3 Solutions

Transcription:

Recall Architecture of Compilers, Interpreters CMSC 330: Organization of Programming Languages Source Scanner Parser Static Analyzer Operational Semantics Intermediate Representation Front End Back End CMSC 330 1 Front end: syntax, (possibly) type checking, other checks Back end: semantics (i.e. execution) CMSC 330 2 Specifying Syntax, Semantics We have seen how the syntax of a programming language may be specified precisely Regular expressions Context-free grammars What about formal methods for defining the semantics of a programming language? I.e., what does a program mean / do? Formal Semantics of a Prog. Lang. Mathematical description of all possible computations performed by programs written in that language Three main approaches to formal semantics Denotational Operational Axiomatic CMSC 330 3 CMSC 330 4

Formal Semantics (cont.) Denotational semantics: translate programs into math! Usually: convert programs into functions mapping inputs to outputs Analogous to compilation Operational semantics: define how programs execute Often on an abstract machine (mathematical model of computer) Analogous to interpretation Axiomatic semantics Describe programs as predicate transformers, i.e. for converting initial assumptions into guaranteed properties after execution! Preconditions: assumed properties of initial states! Postcondition: guaranteed properties of final states Logical rules describe how to systematically build up these transformers from programs This Course: Operational Semantics We will show how an operational semantics may be defined using a subset of OCaml Approach: use rules to define a relation E v E: expression in OCaml subset v: value that results from evaluating E To begin with, need formal definitions of: Set Exp of expressions Set Val of values CMSC 330 5 CMSC 330 6 Defining Exp Recall: operational semantics defines what happens in backend Front end parses code into abstract syntax trees (ASTs) So inputs to backend are ASTs How to define ASTs? Standard approach! Using grammars! Idea! Grammar defines abstract syntax (no parentheses, grouping constructs, etc.; grouping is implicit) OCaml Abstract Syntax E ::= x n true false [] E op E (op {+,-,/,*,=,<,>,::, etc.}) l_op E (l_op =9 N if E then E else E fun x E E E let x = E in E x may be any identifier n is any numeral (digit sequence, with optional -). true and false stand for the two boolean constants [] is the empty list Exp = set of (type-correct) ASTs defined by grammar Note that the grammar is ambiguous OK because not using grammar for parsing But for defining the set of all syntactically legal terms CMSC 330 7 CMSC 330 8

Values What can results be? Integers Booleans Lists Functions We will deal with first three initially Formal Definition of Val Let Z = {, -1, 0, -1, } be the (math) set of integers B = {ff, tt} be the (math) set of booleans nil be a distinguished value (empty list) Then Val is the smallest set such that Z, B Val and nil 56 If v 1, v 2 56 = A T U 56 Smallest set? Every integer and boolean is a value, as is nil Any pair of values is also a value CMSC 330 9 CMSC 330 10 Operations on Val Basic operations will be assumed +, -, *, /, =, <,, etc. Not all operations are applicable to all values! tt + ff is undefined So is 1 + nil A key purpose of type checking is to prevent these undefined operations from occurring during execution Implementing Exp, Val in OCaml E ::= x n true false [] if E then E else E fun x = E E E let x = E in E type ast = Id of string Num of int Bool of bool Nil If of ast * ast * ast Fun of string * ast App of ast * ast Let of string * ast * ast Val type value = Val_Num of int Val_Bool of bool Val_Nil Val_Pair of value * value CMSC 330 11 CMSC 330 12

Defining Evaluation ( H 1 H n C SOS Rules: Basic Values Approach is inductive and uses rules: Idea: if the conditions H 1 H n ( hypotheses ) are true, the rule says the condition C ( conclusion ) below the line follows Hypotheses, conclusion are statements about ; hypotheses involve subexpressions of conclusions If n=0 (no hypotheses) then the conclusion is automatically true and is called an axiom! A - may be written in place of the hypothesis list in this case! Terminology: statements one is trying to prove are called judgments This method is often called Structural Operational Semantics (SOS) or Natural Semantics CMSC 330 13 false Each basic entity evaluates to its corresponding value Note: axioms! n A [] A CMSC 330 14 true SOS Rules: Built-in Functions How about built-in functions (+, -, etc.)? In OCaml, type-checking done in front end Thus, ASTs coming to back end are type-correct So we assume Exp contains type-correct ASTs We will use relevant operations on value side SOS Rules: Built-in Functions For arithmetic, comparison operations, etc. E 1 E 2 E 1 op E 2 For :: E 1 E 2 E 1 :: E 2 T U Rules are recursive :: is implemented using pairing Type system guarantees result is list CMSC 330 15 CMSC 330 16

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 Rules for hd, tl E T U hd E E T U tl E 3 3 4 4 (3 + 4) 7 5 (3 + 4) + 5 12 5 Note that the rules only apply if E evaluates to a pair of values Nothing in this rule requires the pair to correspond to a list The OCaml type system ensures this CMSC 330 17 CMSC 330 18 Error Cases E 1 E 2 E 1 + E 2 Rules for If What if v 1, v 2 aren t integers? E.g., what if we write false + true? It can be parsed in OCaml, but type checker will disallow it from being passed to back end In a language with dynamic strong typing (e.g. Ruby), rules include explicit type checks E 1 Z E 2 Z E 1 + E 2 Convention: if no rules are applicable to an expression, its result is an error CMSC 330 19 E 1 E 2 if E 1 then E 2 else E 3 E 1 E 3 ( if E 1 then E 2 else E 3 ( Notice that only one branch is evaluated E.g. if true then 3 else 4 3 if false then 3 else 4 4 CMSC 330 20

Using Rules to Define Evaluation E = 9E 6A9 A 6 D 6A 7 7 P 2D E E 6D = 6 E A 6 6 AE D E = E = = E E =6 7 A D 9 P 1 D 6AE E 2D E 6A 7 AE D 9 A 6 6 9 D 9 6E= A 3= E A A 6 - E N P / D AE E 6A E E 6 E A A D 6A Rules for Identifiers The previous rules handle expressions that involve constants (e.g. 1, true) and operations What about variables? These are allowed as expressions How do we evaluate them? In a program, variables must be declared The values that are part of the declaration are used to evaluate later occurrences of the variables We will use environments to hold these declarations in our semantics CMSC 330 21 CMSC 330 22 Environments Mathematically, an environment is a partial function from identifiers to values If A is an environment, and id is an identifier, then A(id) can either be a value (intuition: the variable has been declared) or undefined (intuition: variable has not been declared) An environment can also be thought of as a table If A is Id Val x 0 y ff then A(x) is 0, A(y) is ff, and A(z) is undefined CMSC 330 23 Notation, Operations on Environments is the empty environment (undefined for all ids) x:v is the environment that maps x to v and is undefined for all other ids If A and A are environments then A, A is the environment defined as follows A (id) if A (id) defined (A, A )(id) = A(id) if A (id) undefined but A(id) defined undefined otherwise Idea: A overwrites definitions in A For brevity, can write, A as just A CMSC 330 24

Semantics with Environments To give a semantics for identifiers, we will extend judgments from E to A; E where A is an environment Idea: A is used to give values to the identifiers in E A can be thought of as containing all the declarations made up to E Existing rules can be modified by inserting A everywhere in the judgments Existing Rules Have To Be Modified E.g. E 1 E 2 E 1 + E 2 becomes A; E 1 A; E 2 A; E 1 + E 2 These modifications can be done systematically CMSC 330 25 CMSC 330 26 Rule for Identifiers. - A; x x is an identifier To determine its value v look it up in A! Rule for Let Binding We evaluate the the first expression, and then evaluate the second expression in an environment extended to include a binding for x A; E 1 A, x:v 1 ; E 2 A; let x = E 1 in E 2 CMSC 330 27 CMSC 330 28

Function Values So far our semantics handles Constants Built-in operations Identifiers What about function definitions? Recall form: fun x E To evaluate these expressions we need to add closures to our set of values Closures are what OCaml function expressions evaluate to A closure consists of Parameter (id) Body (expression) Environment (used to evaluate free variables in body) Formal extension to Val if x is an id, E is an expression, and A is an environment then (A, λx.e) Val CMSC 330 29 CMSC 330 30 Rule for Function Definitions The expression evaluates to a closure The id and body in the closure come from the expression The environment is the one in effect when the expression is evaluated This will be used to implement static scope A; fun x E A, Evaluating Function Application How do we evaluate a function application expression of the form E 1 E 2? Static scope Call by value Strategy Evaluate E 1, producing v 1 If v 1 is indeed a function (i.e. closure) then! Evaluate E 2, producing v 2! Set the parameter of closure v 1 equal to v 2! Evaluate the body under this binding of the parameter! Remember that non-parameter ids in the body must be interpreted using the closure! CMSC 330 31 CMSC 330 32

Rule for Function Application Example: (fun x x + 3) 4 A; E 1. A; E 2 A, x:v 2 ; E A; E 1 E 2 1 st hypothesis: E 1 evaluates to a closure 2 nd hypothesis: E 2 produces a value (call by value!) 3 rd hypothesis: Body E in modified closure environment produces a value This last value is the result of the application CMSC 330 33, x:4; x 4, x:4; 3 3 ; fun x x + 3 (, λx.x + 3) ; 4 4, x:4; x + 3 7 ; (fun x x + 3) 4 7 CMSC 330 34 Example: (fun x (fun y x + y)) 3 4 Example (cont.) ; (fun x (fun y x + y)) (, λx.(fun y x + y)),x:3, y:4; x 3,x:3, y:4; y 4 ; 3 3 x:3; (fun y x + y) (x:3, λy.(x + y)) ; (fun x (fun y x + y)) 3 (x:3, λy.(x + y)) ; <previous> (x:3, λy.(x + y)) ; 4 4 x:3, y:4; (x + y) 7 ; ( <previous> 4 ) 7 Let <previous> = (fun x (fun y x + y)) 3 CMSC 330 35 CMSC 330 36

Dynamic Scoping The previous rule for functions implements static scoping, since it implements closures We could easily implement dynamic scoping A; E 1. A; E 2 A, x:v 2 ; E A; E 1 E 2 In short: use the current environment A, not A Easy to see the origins of the dynamic scoping bug! Question: How might you use both? CMSC 330 37 Practice Examples Give a derivation that proves the following (where is the empty environment) ; let x = 5 in let y = 7 in x+y ; - - ) A A, ; - A ) A + ; - ) A - A A - A + E A = 9 A6 E A DE A = A A 6 6 A D D ; - ) A - A A - A + ( CMSC 330 38