The Environment Model

Similar documents
The Environment Model. Nate Foster Spring 2018

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

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

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

CS Lecture 7: The dynamic environment. Prof. Clarkson Spring Today s music: Down to Earth by Peter Gabriel from the WALL-E soundtrack

The Substitution Model

Type Inference. Prof. Clarkson Fall Today s music: Cool, Calm, and Collected by The Rolling Stones

The Substitution Model. Nate Foster Spring 2018

CS 360 Programming Languages Interpreters

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

Interpreters. Prof. Clarkson Fall Today s music: Step by Step by New Kids on the Block

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

Environments

CSci 4223 Lecture 12 March 4, 2013 Topics: Lexical scope, dynamic scope, closures

Semantic Analysis. Lecture 9. February 7, 2018

To figure this out we need a more precise understanding of how ML works

CMSC 330: Organization of Programming Languages. Operational Semantics

CS558 Programming Languages

6.001 Notes: Section 15.1

CS Lecture 6: Map and Fold. Prof. Clarkson Fall Today s music: Selections from the soundtrack to 2001: A Space Odyssey

CS 11 Ocaml track: lecture 7

CSE413: Programming Languages and Implementation Racket structs Implementing languages with interpreters Implementing closures

Data Types. Prof. Clarkson Fall Today s music: Pokémon Theme by Jason Paige

6.184 Lecture 4. Interpretation. Tweaked by Ben Vandiver Compiled by Mike Phillips Original material by Eric Grimson

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

Recap: Functions as first-class values

CMSC 330: Organization of Programming Languages

CS558 Programming Languages

Typical workflow. CSE341: Programming Languages. Lecture 17 Implementing Languages Including Closures. Reality more complicated

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

6.037 Lecture 4. Interpretation. What is an interpreter? Why do we need an interpreter? Stages of an interpreter. Role of each part of the interpreter

So what does studying PL buy me?

CS 330 Lecture 18. Symbol table. C scope rules. Declarations. Chapter 5 Louden Outline

CS Lecture 6: Map and Fold. Prof. Clarkson Spring Today s music: Selections from the soundtrack to 2001: A Space Odyssey

The Compiler So Far. Lexical analysis Detects inputs with illegal tokens. Overview of Semantic Analysis

Announcements. The current topic: Scheme. Review: BST functions. Review: Representing trees in Scheme. Reminder: Lab 2 is due on Monday at 10:30 am.

CS558 Programming Languages

Modular Programming. Prof. Clarkson Fall Today s music: "Giorgio By Moroder" by Daft Punk

Syntax Errors; Static Semantics

Semantic Analysis. Outline. The role of semantic analysis in a compiler. Scope. Types. Where we are. The Compiler so far

The role of semantic analysis in a compiler

CS558 Programming Languages

Every language has its own scoping rules. For example, what is the scope of variable j in this Java program?

CS1622. Semantic Analysis. The Compiler So Far. Lecture 15 Semantic Analysis. How to build symbol tables How to use them to find

Mutable Data Types. Prof. Clarkson Fall A New Despair Mutability Strikes Back Return of Imperative Programming

CMSC 330: Organization of Programming Languages. OCaml Imperative Programming

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

CSE 12 Abstract Syntax Trees

CSCE 314 Programming Languages. Type System

Semantic Analysis. Outline. The role of semantic analysis in a compiler. Scope. Types. Where we are. The Compiler Front-End

The Compiler So Far. CSC 4181 Compiler Construction. Semantic Analysis. Beyond Syntax. Goals of a Semantic Analyzer.

Racket. CSE341: Programming Languages Lecture 14 Introduction to Racket. Getting started. Racket vs. Scheme. Example.

Lecture 13 CIS 341: COMPILERS

Compiler construction

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.

A Third Look At ML. Chapter Nine Modern Programming Languages, 2nd ed. 1

EI326 ENGINEERING PRACTICE & TECHNICAL INNOVATION (III-G) Kenny Q. Zhu Dept. of Computer Science Shanghai Jiao Tong University

Functional abstraction. What is abstraction? Eating apples. Readings: HtDP, sections Language level: Intermediate Student With Lambda

Functional abstraction

ob-ject: to feel distaste for something Webster's Dictionary

Whereweare. CS-XXX: Graduate Programming Languages. Lecture 7 Lambda Calculus. Adding data structures. Data + Code. What about functions

Lecture 15 CIS 341: COMPILERS

Anatomy of a Compiler. Overview of Semantic Analysis. The Compiler So Far. Why a Separate Semantic Analysis?

Lecture 3: Recursion; Structural Induction

UNIVERSITY OF CALIFORNIA Department of Electrical Engineering and Computer Sciences Computer Science Division. P. N. Hilfinger

CS 242. Fundamentals. Reading: See last slide

CMSC 330: Organization of Programming Languages

CSE 341: Programming Languages

CS 11 Haskell track: lecture 1

Topics Covered Thus Far CMSC 330: Organization of Programming Languages

FUNCTIONAL PROGRAMMING

Programs as data first-order functional language type checking

Functions & First Class Function Values

Compilers: The goal. Safe. e : ASM

Static Semantics. Lecture 15. (Notes by P. N. Hilfinger and R. Bodik) 2/29/08 Prof. Hilfinger, CS164 Lecture 15 1

Programming Languages

Lecture 5: The Untyped λ-calculus

CSE450. Translation of Programming Languages. Lecture 11: Semantic Analysis: Types & Type Checking

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

CS558 Programming Languages. Winter 2013 Lecture 3

An Introduction to Functions

Functional Languages. CSE 307 Principles of Programming Languages Stony Brook University

Data Types. Guest Lecture: Andrew Myers Spring 2018

CS Lecture 5: Pattern Matching. Prof. Clarkson Fall Today s music: Puff, the Magic Dragon by Peter, Paul & Mary

CSCI-GA Scripting Languages

G Programming Languages - Fall 2012

CMSC 330: Organization of Programming Languages. OCaml Imperative Programming

CS558 Programming Languages

Map and Fold. Prof. Clarkson Fall Today s music: Selections from the soundtrack to 2001: A Space Odyssey

Functional Programming. Pure Functional Programming

G Programming Languages Spring 2010 Lecture 4. Robert Grimm, New York University

LECTURE 3. Compiler Phases

CMSC 330: Organization of Programming Languages. OCaml Higher Order Functions

Ways to implement a language

CS 6110 S11 Lecture 12 Naming and Scope 21 February 2011

Futures. Prof. Clarkson Fall Today s music: It's Gonna be Me by *NSYNC

UNIVERSITY OF CALIFORNIA Department of Electrical Engineering and Computer Sciences Computer Science Division

Async. Prof. Clarkson Fall Today s music: It's Gonna be Me by *NSYNC

TAIL RECURSION, SCOPE, AND PROJECT 4 11

Lecture #23: Conversion and Type Inference

Transcription:

The Environment Model Prof. Clarkson Fall 2017 Today s music: Selections from Doctor Who soundtracks by Murray Gold

Review Previously in 3110: Interpreters: ASTs, evaluation, parsing Formal syntax: BNF Formal semantics: dynamic: small-step substitution model static semantics Today: More formal dynamic semantics: large-step, environment model

Review Small-step substitution model: substitute value for variable in body of let and functions Good mental model Not efficient: too much substitution at run time Big-step environment model: maintain a dictionary that binds variables to values What OCaml really does

New evaluation relation Big-step semantics: we model just the reduction from the original expression to the final value Suppose e --> e' -->... --> v Abstract to e ==> v forget intermediate expressions read as e evaluates down to v, equiv. e big-steps to v textbook notation: e v Goal: for all expressions e and values v, e ==> v if and only if e -->* v A 4110 theorem

Values Constants are already done evaluating 42 ==> 42 true ==> true In fact, all values big-step to themselves v ==> v

Operator evaluation e1 + e2 ==> v if e1 ==> i1 and e2 ==> i2 and v is the result of primitive operation i1 + i2 e.g., "big" ^ "red" ==> "bigred" 1 + 2 ==> 3 1 + (2+3) ==> 6

Variables What does a variable name evaluate to? x ==>??? Trick question: we don t have enough information to answer it Need to know what value variable was bound to e.g., let x = 2 in x+1 e.g., (fun x -> x+1) 2 e.g., match 2 with x -> x+1 All evaluate to 3, but we reach a point where we need to know binding of x Until now, we've never needed this, because we always substituted before we ever get to a variable name

Variables OCaml doesn't actually do substitution (fun x -> 42) 0 waste of runtime resources to do substitution inside 42 Instead, OCaml lazily substitutes by maintaining dynamic environment

Dynamic environment Dictionary of bindings of all current variables Changes throughout evaluation: No bindings at $: $ let x = 42 in let y = false in e One binding {x:42} at $: let x = 42 in $ let y = false in e Two bindings {x:42,y:false} at $: let x = 42 in let y = false in $ e

Variable evaluation To evaluate x in environment env Look up value v of x in env Return v Type checking guarantees that variable is bound, so we can t ever fail to find a binding in dynamic environment

Evaluation relation Extended notation: <env, e> ==> v Meaning: in dynamic environment env, expression e big-steps to value v <env, e> is called a machine configuration

Variable evaluation <env, x> ==> v if v = env(x) env(x): meaning: the value to which env binds x think of it as looking up x in dictionary env

Redo: evaluation with environment <env, v> ==> v <env, e1 + e2> ==> v if <env, e1> ==> i1 and <env, e2> ==> i2 and v is the result of primitive operation i1+i2

Let expressions To evaluate let x = e1 in e2 in environment env Evaluate the binding expression e1 to a value v1 in environment env <env, e1> ==> v1 Extend the environment to bind x to v1 env = env[x -> v1] new notation Evaluate the body expression e2 to a value v2 in extended environment env <env, e2> ==> v2 Return v2

Let expression evaluation rule <env, let x=e1 in e2> ==> v2 if <env, e1> ==> v1 and <env[x -> v1], e2> ==> v2 Example: (let {} be the empty environment) <{},let x = 42 in x> ==> 42 Because... <{}, 42> ==> 42 and <{}[x -> 42], x> ==> 42 Because {x:42}(x)=42

Function values v1.0 Anonymous functions are values: <env, fun x -> e> ==> fun x -> e

Function application v1.0 To evaluate e1 e2 in environment env Evaluate e1 to a value v1 in environment env <env,e1> ==> v1 Note that v1 must be a function value fun x -> e because function application type checks Evaluate e2 to a value v2 in environment env <env,e2> ==> v2 Extend environment to bind formal parameter x to actual value v2 env = env[x -> v2] Evaluate body e to a value v in environment env <env,e> ==> v Return v

Function application rule v1.0 <env,e1 e2> ==> v if <env,e1> ==> fun x -> e and <env,e2> ==> v2 and <env[x -> v2],e> ==> v Example: <{},(fun x -> x) 1> ==> 1 b/c <{},fun x -> x> ==> fun x -> x and <{},1> ==> 1 and <{}[x -> 1], x> ==> 1

Question What do you think this expression should evaluate to? let x = 1 in let f = fun y -> x in let x = 2 in f 0 A. 1 B. 2

Scope: OCaml What does OCaml say this evaluates to? let x = 1 in let f = fun y -> x in let x = 2 in f 0 - : int = 1

Scope: our semantics What does our semantics say? let x = 1 in {x:1} let f = fun y -> x in {x:1,f:(fun y->x)} let x = 2 in {x:2,f:(fun y->x)} f 0 <{x:2,f:(fun y->x)}, f 0> ==>??? 1. Evaluate f to a value, i.e., fun y->x 2. Evaluate 0 to a value, i.e., 0 3. Extend environment to map parameter: {x:2, f:(fun y->x), y:0} 4. Evaluate body x in that environment 5. Return 2 2 <> 1

Why different answers? Two different rules for variable scope: Rule of dynamic scope (our semantics so far) Rule of lexical scope (OCaml)

Dynamic scope Rule of dynamic scope: The body of a function is evaluated in the current dynamic environment at the time the function is called, not the old dynamic environment that existed at the time the function was defined. Causes our semantics to use latest binding of x Thus return 2

Lexical scope Rule of lexical scope: The body of a function is evaluated in the old dynamic environment that existed at the time the function was defined, not the current environment when the function is called. Causes OCaml to use earlier binding of x Thus return 1

Lexical scope Rule of lexical scope: The body of a function is evaluated in the old dynamic environment that existed at the time the function was defined, not the current environment when the function is called. Causes OCaml to use earlier binding of x Thus return 1

Lexical vs. dynamic scope Consensus after decades of programming language design is that lexical scope is the right choice it supports the Principle of Name Irrelevance: name of variable shouldn't matter to meaning of program programmers free to change names of local variables type checker can prevent more run-time errors Dynamic scope is useful in some situations Some languages use it as the norm (e.g., Emacs LISP, LaTeX) Some languages have special ways to do it (e.g., Perl, Racket) But most languages just don t have it Exception handling resembles dynamic scope: raise e transfers control to the most recent exception handler like how dynamic scope uses most recent binding of variable 26

Implementing time travel Q: How can functions be evaluated in old environments? A: The language implementation keeps old environments around as necessary 27

Implementing time travel A function value is really a data structure called a function closure that has two parts: The code, an expression e The environment env that was current when the function was defined We'll notate that data structure as ( e, env ) ( e, env ) is like a pair But indivisible: you cannot write OCaml syntax to access the pieces And inexpressible: you cannot directly write it in OCaml syntax

Function application v2.0 orange = changed from v1.0 To evaluate e1 e2 in environment env Evaluate e1 to a value v1 in environment env <env,e1> ==> v1 Note that v1 must be closure ( fun x -> e, defenv ) Evaluate e2 to a value v2 in environment env <env,e2> ==> v2 Extend closure environment to bind formal parameter x to actual value v2 env = defenv[x -> v2] Evaluate body e to a value v in environment env <env,e> ==> v Return v

Function application rule v2.0 <env, e1 e2> ==> v if <env, e1> ==> ( fun x -> e, defenv ) and <env, e2> ==> v2 and <defenv[x -> v2], e> ==> v

Function values v2.0 Anonymous functions fun x-> e are closures: <env, fun x -> e> ==> ( fun x -> e, env )

Closures in OCaml bytecode compiler https://github.com/ocaml/ocaml/search?q=kclosure

Closures in Java Nested classes can simulate closures Used everywhere for Swing GUI! http://docs.oracle.com/javase/tutorial/uiswing/ events/generalrules.html#innerclasses You ve done it yourself already in 2110 Java 8 adds higher-order functions and closures

Closures in C In C, a function pointer is just a code pointer, period. No environment. To simulate closures, a common idiom: Define function pointers to take an extra, explicit environment argument But without generics, no good choice for type of list elements or the environment Use void* and various type casts From Linux kernel: http://lxr.free-electrons.com/source/include/linux/ kthread.h#l13 34

Interpreter for expr. lang. See interp4.ml in code for this lecture for implementation with closures

Upcoming events [today or tomorrow] A4 out This is closure. THIS IS 3110