CS 342 Lecture 8 Data Abstraction By: Hridesh Rajan

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

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

A Brief Introduction to Scheme (II)

Functional Programming. Pure Functional Programming

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

CS 342 Lecture 7 Syntax Abstraction By: Hridesh Rajan

Lecture 3: Expressions

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

Scheme in Scheme: The Metacircular Evaluator Eval and Apply

Lecture08: Scope and Lexical Address

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

Type Inference and Type Habitation (5/10/2004)

An Explicit-Continuation Metacircular Evaluator

6.037 Lecture 7B. Scheme Variants Normal Order Lazy Evaluation Streams

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

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

C311 Lab #3 Representation Independence: Representation Independent Interpreters

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

CS 275 Name Final Exam Solutions December 16, 2016

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

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

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

Comp 311: Sample Midterm Examination

Lecture 16: Object Programming Languages

Lecture 12: Conditional Expressions and Local Binding

Introduction to Scheme

Using Symbols in Expressions (1) evaluate sub-expressions... Number. ( ) machine code to add

Project 2: Scheme Interpreter

Essentials of Programming Languages Language

Essentials of Programming Languages Language

Discussion 12 The MCE (solutions)

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

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

Principles of Programming Languages

Normal Order (Lazy) Evaluation SICP. Applicative Order vs. Normal (Lazy) Order. Applicative vs. Normal? How can we implement lazy evaluation?

Building a system for symbolic differentiation

Konzepte von Programmiersprachen

CSc 520 Principles of Programming Languages

From Syntactic Sugar to the Syntactic Meth Lab:

CS61A Midterm 2 Review (v1.1)

1. For every evaluation of a variable var, the variable is bound.

CMSC 330: Organization of Programming Languages

Functional Programming. Pure Functional Languages

Principles of Programming Languages

Data abstraction, revisited

Lexical vs. Dynamic Scope

(scheme-1) has lambda but NOT define

Building a system for symbolic differentiation

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

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

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

CS61A Discussion Notes: Week 11: The Metacircular Evaluator By Greg Krimer, with slight modifications by Phoebus Chen (using notes from Todd Segal)

Deferred operations. Continuations Structure and Interpretation of Computer Programs. Tail recursion in action.

Review Analyzing Evaluator. CS61A Lecture 25. What gets returned by mc-eval? (not analyzing eval) REVIEW What is a procedure?

Functional Programming. Pure Functional Languages

Building up a language SICP Variations on a Scheme. Meval. The Core Evaluator. Eval. Apply. 2. syntax procedures. 1.

Procedural abstraction SICP Data abstractions. The universe of procedures forsqrt. Procedural abstraction example: sqrt

Overview. CS301 Session 3. Problem set 1. Thinking recursively

6.945 Adventures in Advanced Symbolic Programming

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

Programming Languages

CSE341 Spring 2017, Final Examination June 8, 2017

CS 314 Principles of Programming Languages

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>)

Lecture 15 CIS 341: COMPILERS

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

Scheme. Functional Programming. Lambda Calculus. CSC 4101: Programming Languages 1. Textbook, Sections , 13.7

Functional Programming - 2. Higher Order Functions

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

Higher-Order Functions (Part I)


6.001: Structure and Interpretation of Computer Programs

6.001 Notes: Section 8.1

More Scheme CS 331. Quiz. 4. What is the length of the list (()()()())? Which element does (car (cdr (x y z))) extract from the list?

Lecture #24: Programming Languages and Programs

CS61A Summer 2010 George Wang, Jonathan Kotker, Seshadri Mahalingam, Eric Tzeng, Steven Tang

Mid-Term 2 Grades

Programming Languages: Application and Interpretation

CS 360 Programming Languages Interpreters

CSC 533: Programming Languages. Spring 2015

CS558 Programming Languages

CSE341, Spring 2013, Final Examination June 13, 2013

CSE341 Spring 2017, Final Examination June 8, 2017

UMBC CMSC 331 Final Exam

Higher-Order Functions

CS 314 Principles of Programming Languages

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

9 Objects and Classes

CS422 - Programming Language Design

CS 342 Lecture 6 Scheme Procedures and Closures By: Hridesh Rajan

SCHEME 7. 1 Introduction. 2 Primitives COMPUTER SCIENCE 61A. October 29, 2015

Typed Racket: Racket with Static Types

COP4020 Programming Assignment 1 - Spring 2011

User-defined Functions. Conditional Expressions in Scheme

CMSC 330: Organization of Programming Languages. Operational Semantics

Working with recursion. From definition to template. Readings: HtDP, sections 11, 12, 13 (Intermezzo 2).

Working with recursion

An Introduction to Scheme

Implementing Recursion

4.2 Variations on a Scheme -- Lazy Evaluation

Transcription:

CS 342 Lecture 8 Data Abstraction By: Hridesh Rajan 1 Com S 342 so far So far we have studied: Language design goals, Basic functional programming, Flat recursion over lists, Notion of Scheme procedures and closures, and Syntax abstraction. 2 Reading EOPL 3rd Edition, Section 2.1-2.5 3 Specifying Data via Interfaces The key ideas that we will learn about are data abstraction and abstract data types (ADT). For example: nonnegative integers. Basic idea is to divide program into 2 parts: 1. knows about representation (the ADT implementation) 2. doesn t know details of representation (the client) Exercise 3.1 What good is this? Allows us to develop data representations gradually. Allows us to change the representation by only changing small number of procedures. 3.1 Representation Independence Definition 3.1 A program exhibits representation independence if it works correctly with any correct implementation of an abstract data type. Example: most programs are independent of the representation for numbers, lists, we ll also be independent of the representation of records. Exercise 3.2 Are C programs independent of the representation of numbers? 1

For a program to be representation independent, it must rely only on the interface (specification) of the data type. For example, consider the data type of natural numbers. The interface of this data type consists of four procedures defined as follows. (zero) =!0! (is-zero?!n!) = #t if n=0 else #f (successor!n!) =!n+1! (n>=0) (predecessor!n+1! =!n! (n>=0) Given this specification, there could be many implementation that obey it. See the unary, Scheme number and Bignum representations on pages 33-34. However, if we write client programs that manipulate natural numbers in accordance with these rules, the interface provides a guarantee that they will produce correct answers irrespective of the representation of the natural numbers in use. Exercise 3.3 Is there any guarantee if clients manipulate natural numbers in a manner that cannot be expressed in terms of the four procedures above? 3.2 Opaque vs. Transparent Definition 3.2 A type is opaque if there is no way to find out its representation, even by printing. Otherwise it is transparent. Exercise 3.4 Which kind does Scheme have? C++? Exercise 3.5 Which kind of date type does Smalltalk has? Exercise 3.6 What s the advantage of an opaque type? of transparent? Opaque enforces use of the defining procedures, has better security, and transparent is easier to debug and extend (which is also a disadvantage!) 4 Representation Strategies for Data Types So far we looked at different representations of the same data types. Next we will study some of the strategies for representing data types. Our example will be a data type for environments. Definition 4.1 An environment is a date type that associates a value with each element of a finite set of variables. In other words, it maps variable names to values. 2

We have mentioned this before, now let us define it concretely! See Section 2.2.1 for description of the specification/interface of this data type. An environment s behavior is defined by the function below: (empty-env) =!empty-set! (apply-env!f! var) = f(var) (extend-env var v!f!) =!g!, where g(var1) = v f(var1) if var1 = var otherwise Exercise 4.7 Extend the environment created on page 36 such that the the variable p is defined as 47 4.1 Data Structure Representation Note that environment is an expression in the following grammar: Env := (empty-env) (extend-env Var SchemeVal Env) Review the data-structure based representation in Figure 2.1 on page 38 of the textbook. Figure 2.1 in textbook. ;;; data definition: ;;; Env ::= (empty-env) (extend-env Var Schemeval Env) ;;; empty-env : () -> Env (define empty-env (lambda () (list empty-env))) ;;; extend-env : Var * Schemeval * Env -> Env (define extend-env (lambda (var val env) (list extend-env var val env))) ;;; apply-env : Env * Var -> Schemeval (define apply-env (lambda (env search-var) (cond ;;; Case of empty environment ((eqv? (car env) empty-env) (report-no-binding-found search-var)) ;;; Case of non-empty environment ((eqv? (car env) extend-env) (let ((saved-var (cadr env)) (saved-val (caddr env)) (saved-env (cadddr env))) (if (eqv? search-var saved-var) saved-val (apply-env saved-env search-var)))) (else (report-invalid-env env))))) 4.2 Procedural Representation The key idea here is to use a higher-order procedure to represent the two constructors of the environment: empty-env, extend-env. These procedures store the mapping between variables and values. ;;; empty-env : () -> Env (define empty-env (lambda () 3

(lambda (search-var) (report-no-binding-found search-var)))) ;;; extend-env : Var * Schemeval * Env -> Env (define extend-env (lambda (saved-var saved-val saved-env) (lambda (search-var) (if (eqv? search-var saved-var) saved-val (apply-env saved-env search-var))))) ;;; apply-env : Env * Var -> Schemeval (define apply-env (lambda (env search-var) (env search-var))) Review the description of data-structure based representation in Figure 2.1 and on pages 40-41 of the textbook. 4.3 Interfaces for Recursive Data Types Why? (Expressions are recursive data types) How? (Follow the recipe) What? (Constructor, Predicate, and Extractors) Include one constructor for each kind of data in the data type. Include one predicate for each kind of data in the data type. Include one extractor for each piece of data passed to a constructor of the data type. Let us apply this to lambda expressions defined the following grammar. Lc-exp ::= Identifier "Variable" (lambda (Identifier) Lc-exp) "Abstraction" (Lc-exp Lc-exp) "Application" What are kinds of data for this data type? Constructors: Predicates: Extractors: Review the general recipe for designing an interface for a recursive data type on page 42 43 of your textbook. Based on this recipe, the interface for the data type lambda expression can be defined as: ;;;Constructors: ;;; var-exp : Var -> Lc-exp (define var-exp (lambda (var) (var-exp,var))) ;;; lambda-exp : Var * Lc-exp -> Lc-exp (define lambda-exp (lambda (var lc-exp) (lambda-exp,var,lc-exp))) ;;; app-exp : Lc-exp * Lc-exp -> Lc-exp (define app-exp (lambda (lc-exp1 lc-exp2) (app-exp,lc-exp1,lc-exp2))) 4

;;;Predicates: ;;; var-exp? : Lc-exp -> Bool (define var-exp? (lambda (x) (and (pair? x) (eq? (car x) var-exp)))) ;;; lambda-exp? : Lc-exp -> Bool (define lambda-exp? (lambda (x) (and (pair? x) (eq? (car x) lambda-exp)))) ;;; app-exp? : Lc-exp -> Bool (define app-exp? (lambda (x) (and (pair? x) (eq? (car x) app-exp)))) ;;;Extractors: ;;; var-exp->var : Lc-exp -> Var (define var-exp->var (lambda (x) (cadr x))) ;;; lambda-exp->bound-var : Lc-exp -> Var (define lambda-exp->bound-var (lambda (x) (cadr x))) ;;; lambda-exp->body : Lc-exp -> Lc-exp (define lambda-exp->body (lambda (x) (caddr x))) ;;; app-exp->rator : Lc-exp -> Lc-exp (define app-exp->rator (lambda (x) (cadr x))) ;;; app-exp->rand : Lc-exp -> Lc-exp (define app-exp->rand (lambda (x) (caddr x))) Note the three type of procedures: constructors, predicates and extractors. 4.4 A Tool for Defining Data Types Why do we need such a tool? For complicated data types, manual definition tedious For example, if a data type has n variants and each variant has m fields, the number of procedures that we have to define are? Avoid errors in data type definitions How do we come up with such a tool? Defining data type interfaces is fairly systematic In fact, we looked at an algorithm for it Defines Constructors, Predicates, Observers So why not use syntax abstraction and abstract away from this abstraction Is it applicable? Does syntax abstraction precisely serves this purpose? Let us revisit the data type for lambda expressions as defined previously. ;;; The form is "define-datatype" ;;; followed by "type name" ;;; followed by "predicate name" for the type. (define-datatype lc-exp lc-exp? 5

;;; A case for each variant/kind of data type. [At least one kind is required] ;;; Each case has the form "variant name" ;;; followed by a "record type". ;;; A record type contains zero or more field declarations ;;; A field declaration has the form (<field-name> <predicate>) ;;; Here is the case for variable (var-exp (var identifier?) ) ;;; Here is the case for abstraction (lambda-exp (bound-var identifier?) (body lc-exp?) ) ) ;;; Here is the case for application (app-exp (rator lc-exp?) (rand lc-exp?) ) Following are the effect of this define-datetype definition. Creates a date-type with specified variants Each variant has a variant-name and 0 or more fields Each field has its own name and associated predicate Creates a new constructor for each variant. Bounds the type predicate name to a predicate, which determines if its argument is a value of the type. Constraints: No two types may have the same name. No two variants have the same name. Type names may not used as variant names. Each field predicate must be a Scheme predicate. As a result of the date type definition above, we now have access to constructors, predicates and extractors. So now we can write the occurs free function of Chapter 1 in terms of these procedures as shown below. See your textbook for more description on this. ;;; Objective is to find if search-var is a free variable in exp. (define occurs-free? (lambda (search-var exp) ;;; Read it as "for each case of exp as defined by data type lc-exp" (cases lc-exp exp ;;; Logic for each case - - Here is the case for var-exp ;;; Read it as: "If exp was of kind var-exp then it would have a field var ;;; and the value of the cases expression would be the value ;;; of expression (eqv? var search-var)" ;;; Has form: (variant-name ({field-name}*) consequent) (var-exp (var) (eqv? var search-var)) ;;; Read it as: "If exp was of kind lambda-exp then it would have two fields and ;;; and the value of the cases expression would be the value of ;;; expression (and ;;; (not (eqv? search-var bound-var)) ;;; (occurs-free? search-var body))" (lambda-exp (bound-var body) (and (not (eqv? search-var bound-var)) (occurs-free? search-var body))) 6

;;; Read it as: "If exp was of kind app-exp then it would have two fields and..." (app-exp (rator rand) (or (occurs-free? search-var rator) (occurs-free? search-var rand)))))) ;;; Additional facts: can have a default case, positional binding. Some more usage can be seen in Section 2.5 in your textbook. Note that entire chapter 2 is on your required reading list for this course. 7