Substitution & Evaluation Order cos 441 David Walker.

Slides:



Advertisements
Similar presentations
Types and Programming Languages Lecture 4 Simon Gay Department of Computing Science University of Glasgow 2006/07.
Advertisements

Types and Programming Languages Lecture 7 Simon Gay Department of Computing Science University of Glasgow 2006/07.
Type Inference David Walker COS 320. Criticisms of Typed Languages Types overly constrain functions & data polymorphism makes typed constructs useful.
The lambda calculus David Walker CS 441. the (untyped) lambda calculus a language of functions e ::= x | \x.e | e1 e2 v ::= \x.e there are several different.
The lambda calculus David Walker CS 441. the lambda calculus Originally, the lambda calculus was developed as a logic by Alonzo Church in 1932 –Church.
Elements of Lambda Calculus Functional Programming Academic Year Alessandro Cimatti
A Type System for Well-Founded Recursion Derek Dreyer Carnegie Mellon University POPL 2004 Venice, Italy.
Catriel Beeri Pls/Winter 2004/5 functional-language 1 Substitution Semantics of FL – a simple functional language FL is EL + (non-recursive) function creation.
1 Introduction to Computability Theory Lecture12: Decidable Languages Prof. Amos Israeli.
6. Introduction to the Lambda Calculus. © O. Nierstrasz PS — Introduction to the Lambda Calculus 6.2 Roadmap  What is Computability? — Church’s Thesis.
Data Abstraction COS 441 Princeton University Fall 2004.
The lambda calculus David Walker CS 441. the lambda calculus Originally, the lambda calculus was developed as a logic by Alonzo Church in 1932 –Church.
Restricted Satisfiability (SAT) Problem
Syntax With Binders COS 441 Princeton University Fall 2004.
Foundations of (Theoretical) Computer Science Chapter 2 Lecture Notes (Section 2.2: Pushdown Automata) Prof. Karen Daniels, Fall 2009 with acknowledgement.
From Chapter 4 Formal Specification using Z David Lightfoot
Chair of Software Engineering 1 Concurrent Object-Oriented Programming Arnaud Bailly, Bertrand Meyer and Volkan Arslan.
MinML: an idealized programming language CS 510 David Walker.
Type Inference David Walker COS 441. Criticisms of Typed Languages Types overly constrain functions & data polymorphism makes typed constructs useful.
Type Inference II David Walker COS 441. Type Inference Goal: Given unannotated program, find its type or report it does not type check Overview: generate.
1 5.The Gamma Function (Factorial Function ) 5.1 Definition, Simple Properties At least three different, convenient definitions of the gamma function are.
Tim Sheard Oregon Graduate Institute Lecture 11: A Reduction Semantics for MetaML CS510 Section FSC Winter 2005 Winter 2005.
1 Relational Algebra and Calculus Yanlei Diao UMass Amherst Feb 1, 2007 Slides Courtesy of R. Ramakrishnan and J. Gehrke.
Restricted Satisfiability (SAT) Problem
The ACL2 Proof Assistant Formal Methods Jeremy Johnson.
10/12/20151 GC16/3C11 Functional Programming Lecture 3 The Lambda Calculus A (slightly) deeper look.
CSE S. Tanimoto Lambda Calculus 1 Lambda Calculus What is the simplest functional language that is still Turing complete? Where do functional languages.
© Kenneth C. Louden, Chapter 11 - Functional Programming, Part III: Theory Programming Languages: Principles and Practice, 2nd Ed. Kenneth C. Louden.
A Theory of Hygienic Macros David Herman, Mitchell Wand Northeastern University.
Type Inference II David Walker COS 441. Type Inference Goal: Given unannotated program, find its type or report it does not type check Overview: generate.
April 14, 2015Applied Discrete Mathematics Week 10: Equivalence Relations 1 Properties of Relations Definition: A relation R on a set A is called transitive.
ELIMINATING LEFT RECURSIVENESS. Abbreviation. “cfg” stands for “context free grammar” Definition. A cfg is left recursive if it contains a production.
© Kenneth C. Louden, Chapter 11 - Functional Programming, Part III: Theory Programming Languages: Principles and Practice, 2nd Ed. Kenneth C. Louden.
CSE 230 The -Calculus. Background Developed in 1930’s by Alonzo Church Studied in logic and computer science Test bed for procedural and functional PLs.
Types and Programming Languages Lecture 6 Simon Gay Department of Computing Science University of Glasgow 2006/07.
1 Formal Semantics. 2 Why formalize? ML is tricky, particularly in corner cases generalizable type variables? polymorphic references? exceptions? Some.
Lambda Calculus Prepared by Manuel E. Bermúdez, Ph.D. Associate Professor University of Florida Programming Language Principles Lecture 11.
CSE-321 Programming Languages -Calculus (II) POSTECH March 27, 2006 박성우.
Types and Programming Languages Lecture 12 Simon Gay Department of Computing Science University of Glasgow 2006/07.
Implementing a Dependently Typed λ -Calculus Ali Assaf Abbie Desrosiers Alexandre Tomberg.
Recursive Data Structures and Grammars  Themes  Recursive Description of Data Structures  Recursive Definitions of Properties of Data Structures  Recursive.
Advanced Formal Methods Lecture 3: Simply Typed Lambda calculus Mads Dam KTH/CSC Course 2D1453, Some material from B. Pierce: TAPL + some from.
1/32 This Lecture Substitution model An example using the substitution model Designing recursive procedures Designing iterative procedures Proving that.
Lesson 3 Formalizing and Implementing Pure Lambda Calculus 1/15/02 Chapters 5.3, 6, 7.
CMSC 330: Organization of Programming Languages Operational Semantics.
Arvind Computer Science and Artificial Intelligence Laboratory M.I.T. L04Ext-1 September 21, 2006http:// Some more thoughts.
Set-theoretical models of untyped -calculus Motivation for models: Better intuition about the formal theory. Consistency results follow by soundness. Completeness.
Types and Programming Languages Lecture 3 Simon Gay Department of Computing Science University of Glasgow 2006/07.
CSE-321 Programming Languages -Calculus (II) POSTECH March 26, 2007 박성우.
CSE-321 Programming Languages Abstract Machine E POSTECH May 1, 2006 박성우.
6/21/20161 Programming Languages and Compilers (CS 421) Reza Zamani Based in part on slides by Mattox Beckman,
1 Proving Properties of Recursive List Functions CS 270 Math Foundations of CS Jeremy Johnson.
A LISP interepreter for the Lambda Calculus Functional Programming
Chapter 2: Lambda Calculus
CS5205: Foundations in Programming Languages
CS 550 Programming Languages Jeremy Johnson
Solving systems of equations
CS 611: Lecture 9 More Lambda Calculus: Recursion, Scope, and Substitution September 17, 1999 Cornell University Computer Science Department Andrew Myers.
September 4, 1997 Programming Languages (CS 550) Lecture 6 Summary Operational Semantics of Scheme using Substitution Jeremy R. Johnson TexPoint fonts.
Disjunctive Normal Form
Env. Model Implementation
Artificial Intelligence
Proving Properties of Recursive Functions and Data Structures
Proving Properties of Recursive List Functions
Typed Arithmetic Expressions
Programming Languages and Compilers (CS 421)
Engineering Aspects of Formal Metatheory
Announcements Quiz 6 HW7 due Tuesday, October 30
CSE S. Tanimoto Lambda Calculus
OBJ first-order functional language based on equational logic
Presentation transcript:

Substitution & Evaluation Order cos 441 David Walker

Reading Pierce Chapter 5: –5.1: intro, op. sem., evaluation order –5.2: encodings of booleans, pairs, numbers, recursion –5.3: substitution

Substitution In order to be precise about the operational semantics of the lambda calculus, we need to define substitution properly For the call-by-value operational semantics, we need to define: –e1 [v/x] where v contains no free variables For other operational semantics, we need: –e1 [e2/x]

Free Variables FV : Given an expression, compute its free variables FV : lambda expression variable set FV(x) = {x} FV(e1 e2) = FV(e1) U FV(e2) FV(\x.e) = FV(e) – {x}

FV as an inductive definition FV(x) = {x} FV(e1 e2) = FV(e1) U FV(e2) FV(\x.e) = FV(e) – {x} FV(x) = {x} FV(e1) = S1 FV(e2) = S2 FV(e1 e2) = S1 U S2 FV(e) = S FV(\x.e) = S – {x} Previous slide: Equivalent definition:

All Variables Vars(x) = {x} Vars(e1 e2) = Vars(e1) U Vars(e2) Vars(\x.e) = Vars(e) U {x}

substitution examples (\x.\y.z z)[\w.w/z] = \x.\y.(\w.w) (\w.w)

examples (\x.\y.z z)[\w.w/z] = \x.\y.(\w.w) (\w.w) (\x.\z.z z)[\w.w/z] = \x.\z.z z

examples (\x.\y.z z)[\w.w/z] = \x.\y.(\w.w) (\w.w) (\x.\z.z z)[\w.w/z] = \x.\z.z z (\x.x z)[x/z] = \x.x x ?

examples (\x.\y.z z)[\w.w/z] = \x.\y.(\w.w) (\w.w) (\x.\z.z z)[\w.w/z] = \x.\z.z z (\x.x z)[x/z] = \x.x x (\x.x z)[x/z] = (\y.y z)[x/z] = \y.y x alpha-equivalent expressions = the same except for consistent renaming of variables

special substitution (ignoring capture issues) definition of e1 [[e/x]] assuming FV(e) Vars(e1) = { }: x [[e/x]] = e y [[e/x]] = y (if y x) e1 e2 [[e/x]] = (e1 [[e/x]]) (e2 [[e/x]]) (\x.e1) [[e/x]] = \x.e1 (\y.e1) [[e/x]] = \y.(e1 [[e/x]]) (if y x)

The Principle of Bound Variable Names Dont Matter when you write let val x = 3 in x + global end you assume you can change the declaration of x to a declaration of y (or other name) provided you systematically change the uses of x. eg: let val y = 3 in y + global end provided that the name you pick doesnt conflict with the free variables of the expression. eg: let val global = 3 in global + global end bad

Alpha-Equivalence in order to avoid variable clashes, it is very convenient to alpha-convert expressions so that bound variables dont get in the way. eg: to alpha-convert \x.e we: 1.pick z such that z not in Vars(\x.e) 2.return \z.(e[[z/x]]) we just defined this form of substitution e[[z/x]] so it is a total function when z is not in Vars(\x.e) terminology: Expressions e1 and e2 are called alpha- equivalent when they are the same after alpha- converting some of their bound variables

capture-avoiding substitution defined inductively on the structure of exps: x [e/x] = e y [e/x] = y (if y x) e1 e2 [e/x] = (e1 [e/x]) (e2 [e/x]) (\x.e1) [e/x] = \x.e1 (\y.e1) [e/x] = \y.(e1 [e/x]) (if y x and y FV(e)) (\y.e1) [e/x] = \z.((e1[[z/y]]) [e/x]) (if y x and y FV(e)) for some z such that z FV(e) U Vars(e1)

Implicit Alpha-Conversion its irritating to explicitly alpha-convert all the time in our definitions. ie: to explicitly write down that before doing something like substitution (or type checking) that we are going to pick some new variable z that doesnt interfere with any other variables in the current context and alpha-convert the given term. Consequently, we are going to take a short-cut: implicit alpha-conversion. When dealing with a bound variable as in \x.e, well just assume that x is any variable we like other than one of the free variables in e.

capture-avoiding substitution (the short-cut definition) x [e/x] = e y [e/x] = y (if y x) e1 e2 [e/x] = (e1 [e/x]) (e2 [e/x]) (\x.e1) [e/x] = \x.e1 (\y.e1) [e/x] = \y.(e1 [e/x]) (if y x and y FV(e)) (note, we left out the case for \y.e1 [e/x] when y x and y FV(e). Well implicitly alpha-convert \y.e1 to \z.e1[[z/y]] for some z that doesnt appear in e1 whenever we need to satisfy the free variable side conditions)

operational semantics again Is this the only possible operational semantics? e1 --> e1 e1 e2 --> e1 e2 e2 --> e2 v e2 --> v e2 (\x.e) v --> e [v/x]

alternatives e1 --> e1 e1 e2 --> e1 e2 e2 --> e2 v e2 --> v e2 (\x.e) v --> e [v/x] e1 --> e1 e1 e2 --> e1 e2 (\x.e1) e2 --> e1 [e2/x] call-by-value call-by-name

alternatives e1 --> e1 e1 e2 --> e1 e2 e2 --> e2 v e2 --> v e2 (\x.e) v --> e [v/x] e1 --> e1 e1 e2 --> e1 e2 (\x.e1) e2 --> e1 [e2/x] call-by-value full beta-reduction e2 --> e2 e1 e2 --> e1 e2 e --> e \x.e --> \x.e

alternatives e1 --> e1 e1 e2 --> e1 e2 e2 --> e2 v e2 --> v e2 (\x.e) v --> e [v/x] call-by-value right-to-left call-by-value e1 --> e1 e1 v --> e1 v e2 --> e2 e1 e2 --> e1 e2 (\x.e) v --> e [v/x]

Multi-step Op. Sem Given a single step op sem. relation: We extend it to a multi-step relation by taking its reflexive, transitive closure: e1 -->* e1 e1 --> e2 e2 -->* e3 e1 -->* e3 e1 --> e2 (reflexivity)(transitivity)

Proving Theorems About O.S. Call-by-value o.s.: To prove property P of e1 --> e2, there are 3 cases: case: e1 --> e1 e1 e2 --> e1 e2 e2 --> e2 v e2 --> v e2 (\x.e) v --> e [v/x] e1 --> e1 e1 e2 --> e1 e2 e2 --> e2 v e2 --> v e2 IH = P(e1 --> e1) Must prove: P(e1 e2 --> e1 e2) IH = P(e2 --> e2) Must prove: P(v e2 --> v e2) Must prove: P((\x.e) v --> e [v/x]) ** Often requires a related property of substitution e [v/x]

Proving Theorems About O.S. Call-by-value o.s.: To prove property P of e1 -->* e2, given youve already proven property P of e1 --> e2, there are 2 cases: case: IH = P(e2 -->* e3) Also available: P(e1 --> e2) Must prove: P(e1 -->* e3) e1 -->* e1 e1 --> e2 e2 -->* e3 e1 -->* e3 (reflexivity) (transitivity) e1 -->* e1 Must prove: P(e1 -->* e1) directly e1 --> e2 e2 -->* e3 e1 -->* e3

Example Definition: An expression e is closed if FV(e) = { }. Theorem: If e1 is closed and e1 -->* e2 then e2 is closed. Proof: by induction on derivation of e1 -->* e2.

summary the operational semantics –primary rule: beta-reduction –depends upon careful definition of substitution –many evaluation strategies definitions/terminology to remember: –free variable –bound variable –closed expression –capture-avoiding substitution –alpha-equivalence; alpha-conversion –call-by-value, call-by-name, full beta reduction