CMSC 330: Organization of Programming Languages - PowerPoint PPT Presentation

Object oriented programming with ocaml
1 / 29

  • Uploaded on
  • Presentation posted in: General

Object Oriented Programming with OCaml. CMSC 330: Organization of Programming Languages. OCaml Data. So far, we’ve seen the following kinds of data: Basic types (int, float, char, string) ‏ Lists One kind of data structure


Download Presentationdownload

CMSC 330: Organization of Programming Languages




Presentation Transcript

Object oriented programming with ocaml

Object Oriented Programming

with OCaml

CMSC 330: Organization of Programming Languages

Ocaml data

CMSC 330

OCaml Data

So far, we’ve seen the following kinds of data:

Basic types (int, float, char, string)‏


One kind of data structure

A list is either [] or h::t, deconstructed with pattern matching


Let you collect data together in fixed-size pieces


How can we build other data structures?

Building everything from lists and tuples is awkward

Data types

CMSC 330

Data Types

Rect and Circle are type constructors- here a shape is either a Rect or a Circle

Use pattern matching to deconstruct values, and do different things depending on constructor

type shape =

Rect of float * float (* width * length *)‏

| Circle of float (* radius *)‏

let area s =

match s with

Rect (wd, ln) -> wd *. ln

| Circle rad -> rad *. rad *. 3.14

area (Rect (3.0, 4.0))‏

area (Circle 3.0)‏

Data types con t

CMSC 330

Data Types, con't.

type shape =

Rect of float * float (* width * length *)‏

| Circle of float (* radius *)‏

let x = [Rect (3.0, 4.0) ; Circle 3.0; Rect (10.0, 22.5)]

What's the type of x?

What's the type of x's first element?

x : shape list


Data types cont d

CMSC 330

Data Types (cont’d)‏

The arity of a constructor is the number of arguments it takes

A constructor with no arguments is nullary

Constructors must begin with uppercase letter




#letextract=functionSome i->i;;

Warning: this pattern-matching is not exhaustive.

Here is an example of a value that is not matched:



This extract function then works as expected on Some … values:

# extract(Some 3);;



# extract None;;


type optional_int =


| Some of int

let add_with_default a = function

None -> a + 42

| Some n -> a + n

add_with_default 3 None (* 45 *)‏

add_with_default 3 (Some 4) (* 7 *)‏

Polymorphic data types

CMSC 330

Polymorphic Data Types

This option type can work with any kind of data

In fact, this option type is built-in to OCaml

type 'a option =


| Some of 'a

let add_with_default a = function

None -> a + 42

| Some n -> a + n

add_with_default 3 None (* 45 *)‏

add_with_default 3 (Some 4) (* 7 *)‏

Recursive data types

CMSC 330

Recursive Data Types

We can build up lists this way:

Note: Don’t have nice [1; 2; 3] syntax for this kind of list

type 'a list =


| Cons of 'a * 'a list

let rec length l = function

Nil -> 0

| Cons (_, t) -> 1 + (length t)‏

length (Cons (10, Cons (20, Cons (30, Nil))))‏


CMSC 330


So far, most everything we’ve defined has been at the “top-level” of OCaml

This is not good software engineering practice

A better idea: Use modules to group associated types, functions, and data together

For lots of sample modules, see the OCaml standard library

Creating a module

CMSC 330

Creating a Module

module Shapes =


type shape =

Rect of float * float (* width * length *)‏

| Circle of float (* radius *)‏

let area = function

Rect (w, l) -> w *. l

| Circle r -> r *. r *. 3.14

let unit_circle = Circle 1.0


unit_circle;; (* not defined *)‏


Shapes.area (Shapes.Rect (3.0, 4.0));;

open Shapes;; (* import all names into current scope *)‏

unit_circle;; (* now defined *)‏

Modularity and abstraction

CMSC 330

Modularity and Abstraction

Another reason for creating a module is so we can hide details

For example, we can build a binary tree module, but we may not want to expose our exact representation of binary trees

This is also good software engineering practice

Module signatures

CMSC 330

Module Signatures

Supply function types

Entry in signature

module type FOO =


val add : int -> int -> int


module Foo : FOO =


let add x y = x + y

let mult x y = x * y


Foo.add 3 4;; (* OK *)‏

Give type to module

Module signatures cont d

CMSC 330

Module Signatures (cont’d)‏

The convention is for signatures to be all capital letters

This isn't a strict requirement, though

Items can be omitted from a module signature

This provides the ability to hide values

The default signature for a module hides nothing

Abstract types in signatures

CMSC 330

Abstract Types in Signatures

Now definition of shape is hidden

module type SHAPES =


type shape

val area : shape -> float

val unit_circle : shape

val make_circle : float -> shape

val make_rect : float -> float -> shape


module Shapes : SHAPES =



let make_circle r = Circle r

let make_rect x y = Rect (x, y)‏


Abstract types in signatures1

CMSC 330

Abstract Types in Signatures

# Shapes.unit_circle

  • : Shapes.shape = <abstr> (* OCaml won’t show impl *)‏

    # Shapes.Circle 1.0

    Unbound Constructor Shapes.Circle

    # Shapes.area (Shapes.make_circle 3.0)‏

  • : float = 29.5788

    # open Shapes;;

    # (* doesn’t make anything abstract accessible *)‏

Note for project 4

CMSC 330

Note for Project 4

You may wish to put the “nfa” type definition in the signature to get better debugging information from Ocaml


Ml and mli files

CMSC 330

.ml and .mli files

General structure: put the signature in a foo.mli file, the struct in a file

Use the same names

Omit the sig...end and struct...end parts

The OCaml compiler will make a Foo module from these

Similar to C file structure (.c/.h)‏

Not implemented in project 4 for simplicity

So far only functional programming

CMSC 330

So Far, only Functional Programming

We haven’t given you any way so far to change something in memory

All you can do is create new values from old

This actually makes programming easier !

You 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 – and there are no side effects!

Imperative ocaml

CMSC 330

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

CMSC 330

Comparison to L- and R-values

Recall that in C/C++/Java, there’s a strong distinction between l- and r-values

A variable's meaning depends on where it appears in an assignment

On the right-hand side, it’s an r-value, and it refers to the contents of the variable

On the left-hand side, it’s an l-value, and it refers to the location the variable is stored in

L values and r values cont d in c

CMSC 330

L-Values and R-Values (cont’d) (in C)‏

Notice that x, y, and 3 all have type int

Store 3 in

location x

Read contents of x and store in location y

int x, y;

x = 3;

y = x;

3 = x;

Makes no sense

Comparison to ocaml

CMSC 330

Comparison to OCaml

In OCaml, an updatable location and the contents of the location have different types

The location has a ref type

let x = ref 0;;

let y = ref 0;;

x := 3;; (* x : int ref *)‏

y := (!x);;

3 := x;; (* 3 : int; error *)‏

int x, y;

x = 3;

y = x;

3 = x;

Application a ref in a closure

CMSC 330

Application: 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;


# next ();;

  • : int = 0

    # next ();;

  • : int = 1


this is how a function

takes no


Semicolon revisited side effects

CMSC 330

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

The trade off of side effects

CMSC 330

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

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

Grouping with begin end

CMSC 330

Grouping with begin...end

If you’re not sure about the scoping rules, use begin...end to group together statements with semicolons

let x = ref 0

let f () =


print_string "hello";

x := (!x) + 1



CMSC 330


exception My_exception of int

let f n =

if n > 0 then

raise (My_exception n)‏


raise (Failure "foo")‏

let bar n =


f n

with My_exception n ->

Printf.printf "Caught %d\n" n

| Failure s ->

Printf.printf "Caught %s\n" s

Exceptions cont d

CMSC 330

Exceptions (cont’d)‏

Exceptions are declared with exception

They may appear in the signature as well

Exceptions may take arguments

Just like type constructors

May also be nullary

Catch exceptions with try...with...

Pattern-matching can be used in with

If an exception is uncaught, the current function exits immediately and control transfers up the call chain until the exception is caught, or until it reaches the top level


CMSC 330



Types & polymorphism

Lists & tuples

Pattern matching

Recursion & inductive definitions

Map and fold


Object-oriented style


Side effects


Ocaml language choices

CMSC 330

OCaml Language Choices

Implicit or explicit variable declarations?

Explicit – variables must be introduced with let before use

But you don’t need to specify types

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

  • Login