Lecture 12: Conditional Expressions and Local Binding

Similar documents
Lecture 09: Data Abstraction ++ Parsing is the process of translating a sequence of characters (a string) into an abstract syntax tree.

Procedures. EOPL3: Section 3.3 PROC and App B: SLLGEN

Lecture 3: Expressions

Mid-Term 2 Grades

Lexical Addresses. let x = 1 y = 2 in let f = proc (x) +(x, y) in (f x) let _ = 1 _ = 2 in let _ = proc (_) +(<0,0>, <1,1>) in (<0,0> <1,0>)

B The SLLGEN Parsing System

Lecture 16: Object Programming Languages

Data Abstraction. An Abstraction for Inductive Data Types. Philip W. L. Fong.

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

Lecture08: Scope and Lexical Address

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

Why do we need an interpreter? SICP Interpretation part 1. Role of each part of the interpreter. 1. Arithmetic calculator.

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

CMSC 330: Organization of Programming Languages

Functional Programming. Pure Functional Programming

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

Comp 311: Sample Midterm Examination

Scheme in Scheme: The Metacircular Evaluator Eval and Apply

CS 360 Programming Languages Interpreters

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

Parsing Scheme (+ (* 2 3) 1) * 1

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

CS 342 Lecture 8 Data Abstraction By: Hridesh Rajan

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

CSSE 304 Assignment #13 (interpreter milestone #1) Updated for Fall, 2018

LECTURE 3. Compiler Phases

C311 Lab #3 Representation Independence: Representation Independent Interpreters

Programs as data first-order functional language type checking

Lecture 2: Data Types and their Representations; Syntax: Scanning and Parsing

Project 2: Scheme Interpreter

Syntax and Grammars 1 / 21

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

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

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

G53CMP: Lecture 4. Syntactic Analysis: Parser Generators. Henrik Nilsson. University of Nottingham, UK. G53CMP: Lecture 4 p.1/32

The Substitution Model

CS 3360 Design and Implementation of Programming Languages. Exam 1

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

Computer Science 21b (Spring Term, 2015) Structure and Interpretation of Computer Programs. Lexical addressing

Principles of Programming Languages

CS 11 Ocaml track: lecture 7

CS 275 Name Final Exam Solutions December 16, 2016

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

Basic Scheme February 8, Compound expressions Rules of evaluation Creating procedures by capturing common patterns

Chapter 3: Describing Syntax and Semantics. Introduction Formal methods of describing syntax (BNF)

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

Streams, Delayed Evaluation and a Normal Order Interpreter. CS 550 Programming Languages Jeremy Johnson

Principles of Programming Languages 2017W, Functional Programming

7. Introduction to Denotational Semantics. Oscar Nierstrasz

Contents. Chapter 1 SPECIFYING SYNTAX 1

Functions & First Class Function Values

Compiler Construction

Lexical vs. Dynamic Scope

CS 314 Principles of Programming Languages

Programming Languages and Compilers (CS 421)

Turtles All The Way Down

cs173: Programming Languages Midterm Exam

Typed Recursion {with {mk-rec : (((num -> num) -> (num -> num)) -> (num -> num)) {fun {body : ((num -> num) -> (num -> num))} {{fun {fx :

Flang typechecker Due: February 27, 2015

Relation Overriding. Syntax and Semantics. Simple Semantic Domains. Operational Semantics

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

The Substitution Model. Nate Foster Spring 2018

Compiler Construction

Compiler construction lecture 3

Lecture 15 CIS 341: COMPILERS

Documentation for LISP in BASIC

Intermediate Representations & Symbol Tables

CMSC330 Spring 2017 Midterm 2

A simple syntax-directed

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.

Ruby: Introduction, Basics

CA Compiler Construction

The Environment Model. Nate Foster Spring 2018

CIS 194: Homework 3. Due Wednesday, February 11, Interpreters. Meet SImPL

Principles of Programming Languages

Programs as data Parsing cont d; first-order functional language, type checking

CS 6353 Compiler Construction Project Assignments

Mandatory Exercise 1 INF3110

Compiler Construction

COMP-421 Compiler Design. Presented by Dr Ioanna Dionysiou

Compiler Construction

Type Inference Systems. Type Judgments. Deriving a Type Judgment. Deriving a Judgment. Hypothetical Type Judgments CS412/CS413

Fall Compiler Principles Lecture 5: Intermediate Representation. Roman Manevich Ben-Gurion University of the Negev

COP 3402 Systems Software Top Down Parsing (Recursive Descent)

Lambda Calculus. Gunnar Gotshalks LC-1

;;; Determines if e is a primitive by looking it up in the primitive environment. ;;; Define indentation and output routines for the output for

The Eval/Apply Cycle Eval. Evaluation and universal machines. Examining the role of Eval. Eval from perspective of language designer

Test I Solutions MASSACHUSETTS INSTITUTE OF TECHNOLOGY Spring Department of Electrical Engineering and Computer Science

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

Fall Compiler Principles Lecture 6: Intermediate Representation. Roman Manevich Ben-Gurion University of the Negev

CS 342 Lecture 7 Syntax Abstraction By: Hridesh Rajan

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

Functional Programming - 2. Higher Order Functions

JavaCC Parser. The Compilation Task. Automated? JavaCC Parser

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

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

Syntactic Sugar: Using the Metacircular Evaluator to Implement the Language You Want

CSE 341 Section 7. Ethan Shea Autumn Adapted from slides by Nicholas Shahan, Dan Grossman, Tam Dang, and Eric Mullen

Fall Semester, The Metacircular Evaluator. Today we shift perspective from that of a user of computer langugaes to that of a designer of

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

Transcription:

Lecture 12: Conditional Expressions and Local Binding Introduction Corresponds to EOPL 3.3-3.4 Please review Version-1 interpreter to make sure that you understand how it works Now we will extend the basic interpreter Version-1 to Version-2 Add new functionality to our PL incorporating: 1. Conditional expressions (if-then-else expressions) 2. Local variable bindings (let expressions) Thereafter we will add user-defined procedures Copyright Bill Havens 1

Conditional Expressions Overview Conditionals essential to any functional PL Consider the utility of a PL without conditionals ( straight-line code ) Approach: 1. Add a BNF rule to the grammar describing the syntax. 2. Annotate the BNF with the abstract syntax describing the node in the abstract syntax tree. 3. Add a new case to our interpreter for evaluating conditional expressions. BNF Rule for Conditional Expressions <expression> ::= if <expression> then <expression> else <expression> Temporary convention: Boolean false = 0; true > 0 Examples: if 1 then 2 else 3 if -(3,+(1,2)) then 2 else 3 Copyright Bill Havens 2

Abstract Datatype Representation New variant of Expression datatype with 3 data fields: if-exp (test-exp then-exp else-exp) Each data field is an Expression datatype recursively Defined datatype for Expression will be created automatically by SLLGEN Implemented by adding a new production to our grammar for SLLGEN: (expression ("if" expression "then" expression "else" expression) if-exp) The specification for SLLGEN says to generate an if-exp abstract datatype record when an if expression is parsed. Copyright Bill Havens 3

Augmented PL Version-2 grammar Now the SLLGEN grammar for Version-2 PL looks like: (define the-grammar '((program (expression) a-program) (expression (number) lit-exp) (expression (identifier) var-exp) (expression (primitive "(" (separated-list expression ",") ")") primappexp) (expression ("if" expression "then" expression "else" expression) if-exp) (primitive ("+") add-prim) (primitive ("-") subtract-prim) (primitive ("*") mult-prim) (primitive ("add1") incr-prim) (primitive ("sub1") decr-prim) )) Copyright Bill Havens 4

Automatically adds a new variant to the expression datatype corresponding to the abstract syntax as follows: (if-exp (test-exp expression?) (true-exp expression?) (false-exp expression?)) Copyright Bill Havens 5

Changes to the Interpreter for PL Version-2 Augmented Interpreter Now we have a parser which generates ASTs for our Version-2 PL But we still have to augment the intepreter to execute our new PL The behavior of a conditional expression is defined by a new case variant in the eval-expression function: (define eval-expression (lambda (exp env) (cases expression exp (lit-exp (datum) datum) (var-exp (id) (apply-env env id)) (primapp-exp (prim rands) (let ((args (eval-rands rands env))) (apply-primitive prim args))) (if-exp (test-exp true-exp false-exp) (if (true-value? (eval-expression test-exp env)) (eval-expression true-exp env) (eval-expression false-exp env))) (else (eopl:error 'eval-expression "Not here:~s" exp)) ))) Copyright Bill Havens 6

Analysis The evaluator recurses on the test-exp and subsequently either the true-exp or the false-exp The operational behavior of the if-exp is defined in terms of the Scheme if expression. The object language semantics is specified in terms of the implementation language Auxiliary Functions Note that the conditional expression is defined in terms of one auxiliary function, true-value?. Since we currently have no boolean expressed values in our PL, we will need to interpret numbers as booleans a zero representing false and any other value representing true. (define true-value? (lambda (x) (not (zero? x)))) Copyright Bill Havens 7

Examples Using the read-eval-print loop, we can test conditional expressions: --> if 1 then 2 else 3 2 --> if -(3, +(1, 2)) then 2 else 3 3 Copyright Bill Havens 8

Local Binding Introduction Finally we add a let expression to our Version-2 PL to allow local bindings. The new expressions will have the following form: let x = 5 y = 6 in +(x, y) Let uses lexical (static) scoping (like Scheme and Java) The body of the let expression is evaluated in an environment containing bindings for the variables in the let expression. Free variable references in the body refer to variables declared in the program text surrounding the let expression Copyright Bill Havens 9

BNF The BNF for let expressions is defined as follows: <expression> ::= let {<identifier> = <expression>}* in <expression> Note that there can be multiple variable declarations in the let expression but only one expression in the body Abstract Datatype Representation New variant of Expression datatype with 3 data fields: let-exp (ids rands body) Defined datatype for Expression variant will be created automatically by SLLGEN Implemented by adding a new production to our grammar for SLLGEN: (expression ("let" (arbno identifier "=" expression) "in" expression) let-exp) The specification for SLLGEN says to generate an let-exp abstract datatype record when a let expression is parsed. Copyright Bill Havens 10

Final PL Version-2 grammar Now the SLLGEN grammar for Version-2 PL looks like: (define the-grammar '((program (expression) a-program) (expression (number) lit-exp) (expression (identifier) var-exp) (expression (primitive "(" (separated-list expression ",") ")") primappexp) (expression ("if" expression "then" expression "else" expression) if-exp) (expression ("let" (arbno identifier "=" expression) "in" expression) let-exp) (primitive ("+") add-prim) (primitive ("-") subtract-prim) (primitive ("*") mult-prim) (primitive ("add1") incr-prim) (primitive ("sub1") decr-prim) )) Copyright Bill Havens 11

Automatically adds a new variant to the expression datatype corresponding to the abstract syntax as follows: (let-exp (ids (list-of symbol?)) (rands (list-of expression?)) (body expression?)) Copyright Bill Havens 12

Final changes to the Interpreter for PL Version-2 Augmented Interpreter Now we have a parser which generates ASTs for our final Version-2 PL Again we have to augment the intepreter to execute our new PL The behavior of a let expression is defined by a new case variant in the evalexpression function: Behavior The interpreter will recurse once for each expression in the variable declarations and once on the body of the let expression When we recurse on the body, we must have an environment with new bindings corresponding to the declarations. Extension of current environment surrounding the let-exp This new environment is passed to the interpreter for eval-expression Copyright Bill Havens 13

Augmented Interpreter for Version-2 PL (define eval-expression (lambda (exp env) (cases expression exp (lit-exp (datum) datum) (var-exp (id) (apply-env env id)) (primapp-exp (prim rands) (let ((args (eval-rands rands env))) (apply-primitive prim args))) (if-exp (test-exp true-exp false-exp) ;\new4 (if (true-value? (eval-expression test-exp env)) (eval-expression true-exp env) (eval-expression false-exp env))) (let-exp (ids rands body) (let ((args (eval-rands rands env))) (eval-expression body (extend-env ids args env)))) (else (eopl:error 'eval-expression "Not here:~s" exp)) ))) Auxiliary function eval-rands evaluates a list of expressions Note that the let inside of the interpreter is NOT interpreting our PL let-exp Copyright Bill Havens 14

Examples We can use the REP loop, to test let expressions: --> let x = 1 in let y = +(x,3) z = 4 in add1(-(y,z)) 1 --> let x = 1 in let x = +(x,2) in add1(x) 4 Copyright Bill Havens 15