OCaml Language Choices CMSC 330: Organization of Programming Languages

Similar documents
CMSC330. Objects, Functional Programming, and lambda calculus

OCaml Data CMSC 330: Organization of Programming Languages. User Defined Types. Variation: Shapes in Java

CMSC 330: Organization of Programming Languages. Objects and Functional Programming

CMSC 330: Organization of Programming Languages. OCaml Imperative Programming

CMSC 330: Organization of Programming Languages. OCaml Imperative Programming

Mutation. COS 326 David Walker Princeton University

Some Advanced ML Features

CMSC 330: Organization of Programming Languages

Dialects of ML. CMSC 330: Organization of Programming Languages. Dialects of ML (cont.) Features of ML. Functional Languages. Features of ML (cont.

Anonymous Functions CMSC 330: Organization of Programming Languages

Tuples. CMSC 330: Organization of Programming Languages. Examples With Tuples. Another Example

Topics Covered Thus Far CMSC 330: Organization of Programming Languages

Topics Covered Thus Far. CMSC 330: Organization of Programming Languages. Language Features Covered Thus Far. Programming Languages Revisited

CMSC 330: Organization of Programming Languages. Closures (Implementing Higher Order Functions)

INF 212 ANALYSIS OF PROG. LANGS FUNCTION COMPOSITION. Instructors: Crista Lopes Copyright Instructors.

Polymorphism. CMSC 330: Organization of Programming Languages. Two Kinds of Polymorphism. Polymorphism Overview. Polymorphism

Background. CMSC 330: Organization of Programming Languages. Useful Information on OCaml language. Dialects of ML. ML (Meta Language) Standard ML

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

CMSC 330: Organization of Programming Languages. Closures (Implementing Higher Order Functions)

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

G Programming Languages - Fall 2012

CMSC 631. Functional Programming with OCaml

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

INF 102 CONCEPTS OF PROG. LANGS FUNCTIONAL COMPOSITION. Instructors: James Jones Copyright Instructors.

Lecture 2, September 4

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

CMSC330 Fall 2013 Practice Problems 6 Solutions

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

Weeks 6&7: Procedures and Parameter Passing

CMSC 330: Organization of Programming Languages

QUIZ. What is wrong with this code that uses default arguments?

Programming Languages and Techniques (CIS120)

Programming Languages. Function-Closure Idioms. Adapted from Dan Grossman's PL class, U. of Washington

CS558 Programming Languages

CS558 Programming Languages

Functional programming Primer I

CS Lectures 2-3. Introduction to OCaml. Polyvios Pratikakis

CSE341: Programming Languages Lecture 9 Function-Closure Idioms. Dan Grossman Winter 2013

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

CMSC 330, Fall 2013, Practice Problem 3 Solutions

public class Foo { private int var; public int Method1() { // var accessible anywhere here } public int MethodN() {

CS 11 Ocaml track: lecture 3

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

Programming Languages and Techniques (CIS120)

Programming Language Features. CMSC 330: Organization of Programming Languages. Turing Completeness. Turing Machine.

CMSC 330: Organization of Programming Languages

CS558 Programming Languages

COSC 2P95. Procedural Abstraction. Week 3. Brock University. Brock University (Week 3) Procedural Abstraction 1 / 26

CSE341: Programming Languages Lecture 9 Function-Closure Idioms. Dan Grossman Fall 2011

Chapter 13 Object Oriented Programming. Copyright 2006 The McGraw-Hill Companies, Inc.

LECTURE 16. Functional Programming

CMSC 330: Organization of Programming Languages. Objects and Abstract Data Types

Topic 7: Algebraic Data Types

CMSC330 Fall 2016 Midterm #1 2:00pm/3:30pm

CMSC 330: Organization of Programming Languages

CMSC 330: Organization of Programming Languages. Functional Programming with Lists

CMSC 330, Fall 2013, Practice Problems 3

CMSC 330: Organization of Programming Languages

Functional Programming and Haskell

CS558 Programming Languages Winter 2018 Lecture 4a. Andrew Tolmach Portland State University

Object-Oriented Principles and Practice / C++

377 Student Guide to C++

CMSC330 Fall 2015 Midterm #1 12:30pm/2:00pm/5:00pm

CS S-24 Final Review I 1

COMP 2355 Introduction to Systems Programming

C++ without Classes. CMSC433, Fall 2001 Programming Language Technology and Paradigms. More C++ without Classes. Project 1. new/delete.

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

CMSC 430 Introduction to Compilers. Fall Everything (else) you always wanted to know about OCaml (but were afraid to ask)

The Haskell HOP: Higher-order Programming

CSE 505: Concepts of Programming Languages

Lecture 7: The Untyped Lambda Calculus

Programming Languages and Techniques (CIS120)

CMSC 330: Organization of Programming Languages

CMSC 330: Organization of Programming Languages. OCaml Expressions and Functions

Programming Languages and Techniques (CIS120)

MARKING KEY The University of British Columbia MARKING KEY Computer Science 260 Midterm #2 Examination 12:30 noon, Thursday, March 15, 2012

Chapter 13: Reference. Why reference Typing Evaluation Store Typings Safety Notes

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

Programming Languages and Techniques (CIS120)

CS 11 Haskell track: lecture 1

Administrivia. Java Review. Objects and Variables. Demo. Example. Example: Assignments

CMSC 330: Organization of Programming Languages. Lets, Tuples, Records

CS131 Typed Lambda Calculus Worksheet Due Thursday, April 19th

CMSC 330: Organization of Programming Languages. Memory Management and Garbage Collection

CMSC 330: Organization of Programming Languages. OCaml Data Types

Types, Type Inference and Unification

COSE212: Programming Languages. Lecture 3 Functional Programming in OCaml

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

CMSC 330: Organization of Programming Languages. Operational Semantics

Mutation. COS 326 Andrew W. Appel Princeton University. slides copyright David Walker and Andrew W. Appel

CS152: Programming Languages. Lecture 7 Lambda Calculus. Dan Grossman Spring 2011

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

COP4020 Programming Assignment 1 - Spring 2011

CSE 341 : Programming Languages Midterm, Spring 2015

Whidbey Enhancements to C# Jeff Vaughan MSBuild Team July 21, 2004

Project Compiler. CS031 TA Help Session November 28, 2011

Introduction to ML. Mooly Sagiv. Cornell CS 3110 Data Structures and Functional Programming

CMSC 330: Organization of Programming Languages. Ownership, References, and Lifetimes in Rust

CMSC330 Spring 2015 Final Exam 9:30am/11:00am/12:30pm

Transcription:

OCaml Language Choices CMSC 330: Organization of Programming Languages! Implicit or explicit declarations?! Explicit variables must be introduced with let before use! But you don t need to specify types Relationships between Functional, Imperative, and Object-Oriented Programming! Static or dynamic types?! Static but you don t need to state types! OCaml does type inference to figure out types for you! Good: less work to write programs! Bad: easier to make mistakes, harder to find errors CMSC 330 2 So Far, only Functional Programming! We haven t given you any way so far to change something in memory in OCaml! All you can do is create new values from old! This actually makes programming easier!! Don t care whether data is shared in memory! Aliasing is irrelevant! Provides strong support for compositional reasoning and abstraction! Ex: Calling a function f with argument x always produces the same result CMSC 330 3 What about Imperative Programming?! In C or Java, we re used to doing things like: int x = 3; int y = 4; void foo(void) { x = 42; y = x + 2; int bar(void) { return x + y;! Can we model this without imperative constructs?! Imperative = able to change values in memory CMSC 330 4

Idea: Thread State through Fns type state = (char * int) list let read (s:state) (x:char):int = List.assoc x s let write (s:state) (x:char) (i:int):state = let s = List.remove_assoc s x in (x,i)::s let foo (s0:state):state = (* could change to state*unit *) let s1 = write s0 x 42 in let s2 = write s1 y ((read s1 x ) + 2) in s2 let bar (s0:state):(state*int) = (s0, (read s0 x ) + (read s0 y )) This Can Actually be a Good Idea! The Haskell language is purely functional! No way to write to memory, ever! But, you can play the trick we just saw! In Haskell, something that behaves like the state type is a monad! Used for a bunch of different things! And there s some interesting theory to go with it! OCaml is only mostly functional! It does actually have imperative constructs CMSC 330 5 CMSC 330 6 Imperative OCaml! There are three basic operations on memory:! ref : 'a -> 'a ref! Allocate an updatable reference!! : 'a ref -> 'a! Read the value stored in reference! := : 'a ref -> 'a -> unit! Write to a reference let x = ref 3 (* x : int ref *) let y =!x x := 4 Comparison to L- and R-values! Recall that in C/C++/Java, there s a strong distinction between l- and r-values! An r-value refers to just a value, like an integer! An l-value refers to a location that can be written l-value y = x; r-value! A variable's meaning depends on where it appears! On the right-hand side, it s an r-value, and it refers to the contents of the variable! On the left-hand side of an assignment, it s an l-value, and it refers to the location the variable is stored in CMSC 330 7 CMSC 330 8

L-Values and R-Values (cont d) Comparison to OCaml Store 3 in location x Makes no sense int x, y; x = 3; y = x; 3 = x; Read contents of x and store in location y int x, y; x = 3; y = x; 3 = x; let x = ref 0;; let y = ref 0;; x := 3;; (* x : int ref *) y := (!x);; 3 := x;; (* 3 : int; error *)! Notice that x, y, and 3 all have type int! In OCaml, an updatable location and the contents of the location have different types! The location has a ref type CMSC 330 9 CMSC 330 10 Capturing a ref in a Closure! We can use refs to make things like counters that produce a fresh number everywhere let next = let count = ref 0 in function () -> let temp =!count in count := (!count) + 1; temp;; # next ();; -! : int = 0 # next ();; -! : int = 1 CMSC 330 11 Semicolon Revisited; Side Effects! Now that we can update memory, we have a real use for ; and () : unit! e1; e2 means evaluate e1, throw away the result, and then evaluate e2, and return the value of e2! () means no interesting result here! It s only interesting to throw away values or use () if computation does something besides return a result! A side effect is a visible state change! Modifying memory! Printing to output! Writing to disk CMSC 330 12

Grouping with begin...end! If you re not sure about the scoping rules, use begin...end to group together statements with semicolons The Trade-Off of Side Effects! Side effects are absolutely necessary! That s usually why we run software! We want something to happen that we can observe let x = ref 0 let f () = begin print_string "hello"; x := (!x) + 1 end! They also make reasoning harder! Order of evaluation now matters! Calling the same function in different places may produce different results! Aliasing is an issue! If we call a function with refs r1 and r2, it might do strange things if r1 and r2 are aliased CMSC 330 13 CMSC 330 14 Object-Oriented Languages The Stack Class! We ve seen how we could model state without imperative features! What about object-oriented constructs?! Can we encode them? class Stack<Typ> { class Entry { Typ elt; Entry next; Entry(Typ e, Entry n) { elt = e; next = n; ; private Entry thestack; void push(typ e) { thestack = new Entry(e, thestack); Typ pop() { if (thestack == null) throw new NoSuchElementException(); Typ temp = thestack.elt; thestack = thestack.next; return temp; CMSC 330 15 CMSC 330 16

Writing a Stack in OCaml: Take 1 module type STACK = sig type 'a stack val new_stack : unit -> 'a stack val push : 'a stack -> 'a -> unit val pop : 'a stack -> 'a end module Stack : STACK = struct type 'a stack = 'a list ref let new_stack () = ref [] let push s x = s := (x::!s) let pop s = match!s with [] -> failwith "Empty stack" (h::t) -> s := t; h end Writing a Stack in OCaml: Take 2 let new_stack () = let this = ref [] in let push x = this := (x::!this) in let pop () = match!this with [] -> failwith "Empty stack" (h::t) -> this := t; h in (push, pop) # let s = new_stack ();; val s : ('_a -> unit) * (unit -> '_a) = (<fun>, <fun>) # fst s 3;; - : unit = () # snd s ();; - : int = 3 CMSC 330 17 CMSC 330 18 Relating Objects and Closures! An object...! Is a collection of fields (data)!...and methods (code)! When a method is invoked, it is passed an implicit this parameter it can use to access fields! A closure...! Is a pointer to an environment (data)!...and a function body (code)! When a closure is invoked, it is passed its environment it can use to access variables CMSC 330 19 Relating Objects and Closures (cont d) class C { int x = 0; void set_x(int y) { x = y; int get_x() { return x; x = 0 C c = new C(); c.set_x(3); int y = c.get_x(); let make () = let x = ref 0 in ( (fun y -> x := y), (fun () ->!x) ) x = ref 0 fun y -> x := y fun () ->!x let (set, get) = make();; set 3;; let y = get ();; CMSC 330 20

Encoding Objects with Lambda Recall a Useful Higher-Order Function! We can apply this transformation in general! becomes class C { f1... fn; m1... mn; let make () = let f1 =... in... let fn =... in ( fun..., (* body of m1 *)... fun..., (* body of mn *) ) let rec map f = function [] -> [] (h::t) -> (f h)::(map f t)! Can we encode this in Java?! make () is like the constructor! the closure environment contains the fields CMSC 330 21 CMSC 330 22 A Map Method for Stack! To write a map method, we need some way of passing a function into another function! We can do that with an object with a known method public interface Function { Object eval(object arg); CMSC 330 23 A Map Method for Stack, cont d! Here are two classes which both implement this Function interface: class AddOne implements Function { Object eval(object arg) { Integer old = (Integer) arg; return new Integer(old.intValue() + 1); class MultTwo implements Function { Object eval(object arg) { Integer old = (Integer) arg; return new Integer(old.intValue() * 2); CMSC 330 24

A Map Method for Stack, cont d A Map Method for Stack, con't. class Stack { class Entry { Object elt; Entry next; Entry(Object x, Entry n) { elt = x; next = n; Entry map(function f) { if (next == null) return new Entry(f.apply(elt), null); else return new Entry(f.apply(elt), next.map(f)); Entry thestack;... Stack map(function f) { Stack s = new Stack(); s.thestack = thestack.map(f); return s; CMSC 330 25! Then to apply the function, we just do Stack s =...; Stack t = s.map(new AddOne()); Stack u = s.map(new MultTwo());! We make a new object that has a method that performs the function we want! This is sometimes called a callback, because map calls back to the object passed into it! But it s really just a higher-order function, written more awkwardly CMSC 330 26 Relating Closures and Objects let app f x = f x a = 3 fun b -> a + b let add a b = a + b;; let f = add 3;; app f 4;; interface F { Object eval(object y); class C { static Object app(f f, Object x) { return f.eval(x); class G implements F { int a; G(int a) { this.a = a; Object eval(object y) { return new Integer(a + ((Integer) y).intvalue()); F adder = new G(3); C.app(adder, 4); a = 3 CMSC 330 27 Encoding Lambda with Objects! We can apply this transformation in general! becomes...(fun x -> (* body of fn *))... let h f... =...f y... interface F { Object eval(object x); class G implements F { Object eval(object x) { /* body of fn */ class C { Typ h(f f,...) {...f.eval(y)...! F is the interface to the callback! G represents the particular function CMSC 330 28

Code as Data! The key insight in all of these examples is to treat code as if it were data! Higher-order functions allow code to be passed around the program! As does object-oriented programming! This is a powerful programming technique! And it can solve a number of problems quite elegantly! Closures and objects are related! Both of them allow data to be associated with higherorder code as its passed around (but we can even get by without this) CMSC 330 29