Programming Languages Dan Grossman 2013

Slides:



Advertisements
Similar presentations
CSE341: Programming Languages Lecture 2 Functions, Pairs, Lists Dan Grossman Winter 2013.
Advertisements

Abstract Syntax Tree Discrete Mathematics and Its Applications Baojian Hua
CSE341: Programming Languages Lecture 16 Datatype-Style Programming With Lists or Structs Dan Grossman Winter 2013.
CSE341: Programming Languages Lecture 24 Racket Modules, Abstraction with Dynamic Types; Racket Contracts Dan Grossman Fall 2011.
CSE341: Programming Languages Lecture 17 Structs, Implementing Languages, Implementing Higher-Order Functions Dan Grossman Fall 2011.
ML: a quasi-functional language with strong typing Conventional syntax: - val x = 5; (*user input *) val x = 5: int (*system response*) - fun len lis =
Introduction to ML - Part 2 Kenny Zhu. What is next? ML has a rich set of structured values Tuples: (17, true, “stuff”) Records: {name = “george”, age.
Introduction to ML Last time: Basics: integers, Booleans, tuples,... simple functions introduction to data types This time, we continue writing an evaluator.
Cs164 Prof. Bodik, Fall Symbol Tables and Static Checks Lecture 14.
CSE341: Programming Languages Lecture 11 Type Inference Dan Grossman Winter 2013.
Programming LanguagesSection 61 Programming Languages Section 6. Racket v.s. ML Xiaojuan Cai Spring 2015.
UNIT 3 TEMPLATE AND EXCEPTION HANDLING. Introduction  Program errors are also referred to as program bugs.  A C program may have one or more of four.
1 Week 4 Questions / Concerns Comments about Lab1 What’s due: Lab1 check off this week (see schedule) Homework #3 due Wednesday (Define grammar for your.
CSE341: Programming Languages Structs, Implementing Languages, Implementing Higher-Order Functions Alan Borning (slides “borrowed” from Dan Grossman) Fall.
CSE 341 Programming Languages Racket Datatype Style Programming Zach Tatlock Spring 2014.
Formal Semantics Chapter Twenty-ThreeModern Programming Languages, 2nd ed.1.
CMSC 330: Organization of Programming Languages
Types in programming languages1 What are types, and why do we need them?
CS536 Semantic Analysis Introduction with Emphasis on Name Analysis 1.
CSE 413 Languages & Implementation Hal Perkins Autumn 2012 Structs, Implementing Languages (credits: Dan Grossman, CSE 341) 1.
CMSC 330: Organization of Programming Languages Operational Semantics a.k.a. “WTF is Project 4, Part 3?”
Interpreters and Higher-Order Functions CSE 413 Autumn 2008 Credit: CSE341 notes by Dan Grossman.
CMSC 330: Organization of Programming Languages Operational Semantics.
CSE341: Programming Languages Lecture 17 Implementing Languages Including Closures Dan Grossman Winter 2013.
Programming Languages Dan Grossman 2013 Datatype-Programming in Racket Without Structs.
Programming Languages Dan Grossman 2013
CSE341: Programming Languages Lecture 11 Type Inference
CSE341: Programming Languages Lecture 17 Implementing Languages Including Closures Dan Grossman Spring 2017.
Programming Languages Dan Grossman 2013
Programming Languages Dan Grossman 2013
CS 4450: Principles of Programming Languages
The interpreter.
Programming Languages Dan Grossman 2013
Semantic Analysis with Emphasis on Name Analysis
CSE341: Programming Languages Lecture 2 Functions, Pairs, Lists
Programming Languages Dan Grossman 2013
CSE341: Programming Languages Lecture 16 Datatype-Style Programming With Lists or Structs Dan Grossman Spring 2013.
Emily Leland (Not Nick) Spring 2017
CSE341: Programming Languages Lecture 16 Datatype-Style Programming With Lists or Structs Zach Tatlock Winter 2018.
CSE341: Programming Languages Lecture 16 Datatype-Style Programming With Lists or Structs Dan Grossman Spring 2017.
Semantics of PLs via Interpreters: Getting Started
CSE341: Programming Languages Lecture 17 Implementing Languages Including Closures Dan Grossman Autumn 2018.
CSE341: Programming Languages Lecture 16 Datatype-Style Programming With Lists or Structs Dan Grossman Autumn 2018.
Preparing for MUPL! Justin Harjanto
CSE341: Programming Languages Lecture 8 Lexical Scope and Function Closures Dan Grossman Spring 2013.
Lecture 15 (Notes by P. N. Hilfinger and R. Bodik)
CSE 341 Section 7 Winter 2018 Adapted from slides by Eric Mullen, Nicholas Shahan, Dan Grossman, and Tam Dang.
CSE341: Programming Languages Lecture 8 Lexical Scope and Function Closures Dan Grossman Spring 2016.
CSE341: Programming Languages Lecture 17 Implementing Languages Including Closures Zach Tatlock Winter 2018.
CSE341: Programming Languages Lecture 2 Functions, Pairs, Lists
CSE341: Programming Languages Lecture 2 Functions, Pairs, Lists
CSE341: Programming Languages Lecture 16 Datatype-Style Programming With Lists or Structs Dan Grossman Autumn 2017.
CSE341: Programming Languages Lecture 11 Type Inference
CSE341: Programming Languages Lecture 2 Functions, Pairs, Lists
CSE341: Programming Languages Lecture 17 Implementing Languages Including Closures Dan Grossman Spring 2016.
Adapted from slides by Nicholas Shahan and Dan Grossman
Adapted from slides by Nicholas Shahan, Dan Grossman, and Tam Dang
Jordi Cortadella and Jordi Petit Department of Computer Science
Nicholas Shahan Spring 2016
CSE341: Programming Languages Lecture 16 Datatype-Style Programming With Lists or Structs Dan Grossman Spring 2016.
CSE341: Programming Languages Lecture 17 Implementing Languages Including Closures Dan Grossman Autumn 2017.
CSE341: Programming Languages Lecture 11 Type Inference
Programming Languages Dan Grossman 2013
CSE341: Programming Languages Lecture 2 Functions, Pairs, Lists
CSE341: Programming Languages Lecture 11 Type Inference
Programming Languages Dan Grossman 2013
CSE341: Programming Languages Lecture 2 Functions, Pairs, Lists
Brett Wortzman Summer 2019 Slides originally created by Dan Grossman
CSE341: Programming Languages Lecture 17 Implementing Languages Including Closures Dan Grossman Spring 2019.
CSE341: Programming Languages Lecture 16 Datatype-Style Programming With Lists or Structs Dan Grossman Spring 2019.
Presentation transcript:

Programming Languages Dan Grossman 2013 What Your Interpreter Can and Cannot Assume

Dan Grossman, Programming Languages What we know Define (abstract) syntax of language B with Racket structs B called MUPL in homework Write B programs directly in Racket via constructors Implement interpreter for B as a (recursive) Racket function Now, a subtle-but-important distinction: Interpreter can assume input is a “legal AST for B” Okay to give wrong answer or inscrutable error otherwise Interpreter must check that recursive results are the right kind of value Give a good error message otherwise Jan-Mar 2013 Dan Grossman, Programming Languages

Dan Grossman, Programming Languages Legal ASTs “Trees the interpreter must handle” are a subset of all the trees Racket allows as a dynamically typed language Can assume “right types” for struct fields const holds a number negate holds a legal AST add and multiply hold 2 legal ASTs Illegal ASTs can “crash the interpreter” – this is fine (struct const (int) #:transparent) (struct negate (e) #:transparent) (struct add (e1 e2) #:transparent) (struct multiply (e1 e2) #:transparent) (multiply (add (const 3) "uh-oh") (const 4)) (negate -7) Jan-Mar 2013 Dan Grossman, Programming Languages

Dan Grossman, Programming Languages Interpreter results Our interpreters return expressions, but not any expressions Result should always be a value, a kind of expression that evaluates to itself If not, the interpreter has a bug So far, only values are from const, e.g., (const 17) But a larger language has more values than just numbers Booleans, strings, etc. Pairs of values (definition of value recursive) Closures … Jan-Mar 2013 Dan Grossman, Programming Languages

Dan Grossman, Programming Languages Example See code for language that adds booleans, number-comparison, and conditionals: What if the program is a legal AST, but evaluation of it tries to use the wrong kind of value? For example, “add a boolean” You should detect this and give an error message not in terms of the interpreter implementation Means checking a recursive result whenever a particular kind of value is needed No need to check if any kind of value is okay (struct bool (b) #:transparent) (struct eq-num (e1 e2) #:transparent) (struct if-then-else (e1 e2 e3) #:transparent) Jan-Mar 2013 Dan Grossman, Programming Languages