An overview of Mezzo

(1)

An overview of Mezzo

François Pottier

INRIA

Bertinoro, June 2015

(2)

Acknowledgements

Jonathan Protzenko, Thibaut Balabonski, Henri Chataing, Armaël Guéneau, Cyprien Mangin.

(3)

What is Mezzo?

Anexperimentalprogramming language in the tradition of ML.

Try it out in your browser:

http://gallium.inria.fr/~protzenk/mezzo-web/

Or install it:

opam install mezzo

(4)

Premise

The types of OCaml, Haskell, Java, C#, etc.:

• describe thestructureof data,

• but do not distinguishtreesandgraphs,

• and do not control who haspermissionto read or write.

(5)

Question

Could a more ambitious static discipline:

• rule outmore programming errors, includingdata races,

• andenablenew programming idioms,

• while remaining reasonablysimpleandﬂexible?

(6)

A quick comparison

In comparison with Tobias Wrigstad's talk (yesterday),

• data race freedomandownership transferare goals too;

• getting rid of GC is not;

• types and permissionsdo notinﬂuence code generation;

they are erased at runtime.

(7)

Outline

A ﬁrst example and a few principles Write-once references: usage Mezzo: (some) design principles

Write-once references: interface & implementation Mezzo: the good and the bad

Algebraic data structures Sharing mutable data Conclusion

(8)

A ﬁrst example and a few principles

Write-once references: usage

(9)

Write-once references

A write-once reference:

• can be writtenat mostonce;

• can be read onlyafterit has been written.

Let us look at a concrete example of use...

(10)

Usage

.

writable...

new

.

frozen .

set

.

get

.

open woref

val r1 = new () (* r1 @ writable *) val r2 = r1

(* r1 @ writable * r2 = r1 *) val () = set (r1, 3);

(* r1 @ frozen int * r2 = r1 *) val x2 = get r2

(* r1 @ frozen int * r2 = r1 * x2 @ int *) val rs = (r1, r2)

(* r1 @ frozen int * r2 = r1 * x2 @ int

* rs @ (=r1, =r2) *)

(* rs @ (frozen int, frozen int) *)

. .

Demo!

(11)

Usage

. writable...

new

.

frozen .

set

.

get

.

open woref

val r1 = new () (* r1 @ writable *)

val r2 = r1

* rs @ (=r1, =r2) *)

. .

Demo!

(12)

Usage

. writable...

new

.

frozen .

set

.

get

.

open woref

(* r1 @ writable * r2 = r1 *)

val () = set (r1, 3);

* rs @ (=r1, =r2) *)

. .

Demo!

(13)

Usage

. writable...

new

.

frozen .

set

.

get

.

open woref

(* r1 @ frozen int * r2 = r1 *)

val x2 = get r2

* rs @ (=r1, =r2) *)

. .

Demo!

(14)

Usage

. writable...

new

.

frozen .

set

.

get

.

open woref

(* r1 @ frozen int * r2 = r1 * x2 @ int *)

val rs = (r1, r2)

* rs @ (=r1, =r2) *)

. .

Demo!

(15)

Usage

. writable...

new

.

frozen .

set

.

get

.

open woref

* rs @ (=r1, =r2) *)

. .

Demo!

(16)

Usage

. writable...

new

.

frozen .

set

.

get

.

open woref

* rs @ (=r1, =r2) *)

. .

Demo!

(17)

Usage

. writable...

new

.

frozen .

set

.

get

.

open woref

* rs @ (=r1, =r2) *)

. .

Demo!

(18)

A ﬁrst example and a few principles

Mezzo: (some) design principles

(19)

Permissions

Like a program logic, the static discipline isﬂow-sensitive.

• Acurrent(set of)permission(s) existsat each program point.

• Diﬀerentpermissions exist at diﬀerent points.

Permissions do not exist at runtime.

(20)

Permissions

Thus, there is no such thing asthetype of a variablex. Instead,

• at each program pointin the scope ofx,

• there may bezero, one, or morepermissions to usex

in certain ways.

(21)

Layout and ownership

Permissions havelayoutandownershipreadings.

• e.g.,r @ writable

x @ tdescribes theshape and extentof a heap fragment, rooted atx, and describes certainaccess rightsfor it.

“To know aboutx” is “to have access tox” is “to ownx”.

(22)

Just two access modes

Every permission is either duplicable or aﬃne.

The basic rules are:

• Immutabledata isduplicable, i.e., shareable.

• Mutabledata isaﬃne, i.e., uniquely owned.

• Mutable data can become immutable; not the converse.

(23)

Aliasing

• Writinglet x = y in ... gives rise to an equationx = y.

• It is a permission: x @ =y, where=yis asingleton type.

• In its presence,x @ tandy @ tare interconvertible.

• Thus,any name is as good as any other.

• The same idea applies tolet x = xs.head in ... .

(24)

Value ̸ = permission

A value can be copied (always). No permission is required.

(* empty *)

let y = (x, x) in (* y @ (=x, =x) *)

(25)

Value ̸ = permission

A duplicable permissioncanbe copied. This is implicit.

(* x @ int *) let y = (x, x) in

(* x @ int * y @ (=x, =x) *)

(* x @ int * y @ (int, int) *)

(26)

Value ̸ = permission

A duplicable permissioncanbe copied. This is implicit.

(* x @ int *) let y = (x, x) in

(* x @ int * y @ (=x, =x) *) (* x @ int * y @ (int, int) *)

(27)

Value ̸ = permission

An aﬃne permissioncannotbe copied.

(* x @ ref int *) let y = (x, x) in

(* x @ ref int * y @ (=x, =x) *)

assert y @ (ref int, ref int) (* WRONG! *)

In other words, mutable data cannot be shared.

(28)

Value ̸ = permission

An aﬃne permissioncannotbe copied.

(* x @ ref int *) let y = (x, x) in

(* x @ ref int * y @ (=x, =x) *)

assert y @ (ref int, ref int) (* WRONG! *)

In other words, mutable data cannot be shared.

(29)

Examples of duplicable versus aﬃne

• x @ list intis duplicable: read access can be shared.

• x = yis duplicable: equalities are forever.

• x @ mlist intandx @ list (ref int)are aﬃne: they give exclusive access to part of the heap.

(30)

Separation

x @ ref int * y @ ref intimpliesxandyare distinct.

Conjunction isseparatingat mutable data.

z @ (t, u)meansz @ (=x, =y) * x @ t * y @ u, forx,yfresh.

Hence, product is separating.

(31)

Separation

The same principle applies to records.

Hence,list (ref int)denotes a list ofdistinctreferences.

Mutable data must betree-structured.

• thoughx @ ref (=x)can be written and constructed.

(32)

A ﬁrst example and a few principles

Write-once references: interface & implementation

(33)

Speciﬁcation

A usage protocol can be described in a module signature:

• Astateis a (user-deﬁned) type.

• Atransitionis a (user-deﬁned) function.

(34)

Speciﬁcation of write-once refs

This protocol has two states and four transitions.

This is the interface ﬁleworef.mzi:

abstract writable ..

abstract frozen a ..

fact duplicable (frozen a) ..

val new: () -> writable ..

val set: [a] (consumes r:.._writable_,.. _x: _a _| _duplicable.._a)

-> (| r @ frozen a) ..

val get: [a] frozen a -> a ..

.

(35)

Speciﬁcation of write-once refs

-> (| r @ frozen a) ..

. .

a state

(36)

Speciﬁcation of write-once refs

-> (| r @ frozen a) ..

. .

another state

(37)

Speciﬁcation of write-once refs

-> (| r @ frozen a) ..

. .

implicit transition from frozen to frozen * frozen

(38)

Speciﬁcation of write-once refs

-> (| r @ frozen a) ..

. .

explicit transition into writable

(39)

Speciﬁcation of write-once refs

-> (| r @ frozen a) ..

. .

set requires r (dynamic) and r @ writable (static)

(40)

Speciﬁcation of write-once refs

-> (| r @ frozen a) ..

. .

consumes keyword means r @ writable NOT returned

(41)

Speciﬁcation of write-once refs

-> (| r @ frozen a) ..

. .

duplicable a is a permission

(42)

Speciﬁcation of write-once refs

-> (| r @ frozen a) ..

. .

explicit transition from writable to frozen

(43)

Speciﬁcation of write-once refs

-> (| r @ frozen a) ..

. .

get r requires r @ frozen a

(44)

Implementation

This is the implementation ﬁleworef.mz:

data mutable writable = Writable { contents: ().._}

data frozen a =

Frozen { contents:.._(a _| _duplicable _{a) }}

val new () : writable = Writable { contents = () }

val set [a] (consumes r: writable, x: a | duplicable a) : (| r @ frozen a) =

.._r.contents _<- _x; ..

tag of r <- Frozen (* this is a no-op *)..

val get [a] (r: frozen a) : a = r.contents

.

(45)

Implementation

data frozen a =

.._r.contents _<- _x; ..

. .

a field of type ()

(46)

Implementation

data frozen a =

.._r.contents _<- _x; ..

. .

a field of type a

where a must be duplicable

(47)

Implementation

data frozen a =

.._r.contents _<- _x; ..

. .

initially, r @ writable

(48)

Implementation

data frozen a =

.._r.contents _<- _x; ..

. .

hence,

r @ Writable { contents: () }

(49)

Implementation

data frozen a =

.._r.contents _<- _x; ..

. .

after the assignment,

r @ Writable { contents: =x }

(50)

Implementation

data frozen a =

.._r.contents _<- _x; ..

. .

hence,

r @ Writable { contents: a }

(51)

Implementation

data frozen a =

.._r.contents _<- _x; ..

. .

after the tag update, r @ Frozen { contents: a }

(52)

Implementation

data frozen a =

.._r.contents _<- _x; ..

. .

hence, r @ frozen a

(53)

A ﬁrst example and a few principles

Mezzo: the good and the bad

(54)

The good

The uniqueness of read/write permissions:

• rules outseveral categories of errors:

• data races; hence,shared-memory concurrency is safe;

• representation exposure;

• violations of (certain) object protocols.

• allowsthe type of an object to vary with time, which enables:

• explicit memory re-use;

• gradual initialization;

• describing (certain) object protocols.

(55)

The good

Here are some other positive aspects:

• all of thepowerof ML, and more;

• higher-order functions, pattern matching, polymorphism, etc.

• no need to annotate types with owners;

• to have a permission is to own

• ownership transferis easy;

• just pass (or return, or store, or extract) a permission

• no need to annotate function types with eﬀects.

• just pass and return a permission

(56)

The good

Moving an elementintoorout ofa container is easy.

Here is a typical container interface:

abstract bag a

val new: [a] () -> bag a

val insert: [a] (bag a, consumes a) -> () val extract: [a] bag a -> option a

(57)

The bad

The disciplineforbids sharingmutable data.

For this reason,borrowingan element from a container is typically restricted toduplicableelements:

val find:

[a]

duplicable a =>

(a -> bool) -> list a -> option a

This aﬀects user-deﬁned data structures, arrays, regions, etc.

(58)

The bad

Fortunately,

• there isno restrictionon the use of immutable data;

• there areseveral waysof sharing mutable data:

• (static) nesting; regions;

• (dynamic) adoption & abandon;

• (dynamic) locks.

(59)

Outline

A ﬁrst example and a few principles Algebraic data structures

(More) Principles

Computing the length of a list Melding mutable lists

Concatenating immutable lists Sharing mutable data

Conclusion

(60)

Algebraic data structures

(More) Principles

(61)

Immutable lists

The algebraic data type of immutable lists is deﬁned as in ML:

data list a =

| Nil

| Cons { head: a; tail: list a }

(62)

Mutable lists

To deﬁne a type of mutable lists, one adds a keyword:

data mutable mlist a =

| MNil

| MCons { head: a; tail: mlist a }

(63)

Examples

For instance,

• x @ list intprovides (read) access to an immutable list of integers, rooted atx.

• x @ mlist intprovides (exclusive, read/write) access to a mutable list of integers atx.

• x @ list (ref int)oﬀers read access to the spine and read/write access to the elements, which are distinct cells.

(64)

Permission reﬁnement

Permission reﬁnement takes place at case analysis.

..

match xs with

| MNil ->

..

...

| MCons ->

..

let x = xs.head in

..

...

end

In contrast, traditional separation logic hasuntaggedunion.

.

(65)

Permission reﬁnement

..

| MNil ->

..

...

| MCons ->

..

...

end

. .

a nominal permission:

xs @ mlist a

(66)

Permission reﬁnement

..

| MNil ->

..

...

| MCons ->

..

...

end

. .

a structural permission:

xs @ MNil

(67)

Permission reﬁnement

..

| MNil ->

..

...

| MCons ->

..

...

end

. .

another structural permission:

xs @ MCons { head: a; tail: mlist a }

(68)

Permission reﬁnement

..

| MNil ->

..

...

| MCons ->

..

...

end

. .

automatically expanded to:

xs @ MCons { head: (=h); tail: (=t) }

* h @ a

* t @ mlist a

(69)

Permission reﬁnement

..

| MNil ->

..

...

| MCons ->

..

...

end

. .

or (sugar):

xs @ MCons { head = h; tail = t }

* h @ a

* t @ mlist a

(70)

Permission reﬁnement

..

| MNil ->

..

...

| MCons ->

..

...

end

. .

so, after the read access:

xs @ MCons { head = h; tail = t }

* h @ a

* t @ mlist a

* x = h

(71)

Principles

This illustrates two mechanisms:

• A nominal permission can beunfoldedandreﬁned, yielding a structural permission.

• A structural permission can bedecomposed,

yielding separate permissions for the block and its ﬁelds.

These reasoning steps are implicit and reversible.

(72)

Algebraic data structures

Computing the length of a list

(73)

Interface

Here is the type of thelengthfunction for mutable lists.

val length: [a] mlist a -> int

It should be understood as follows:

• lengthrequires one argumentxs,

along with the permissionxs @ mlist a.

• lengthreturns one resultn,

along with the permissionxs @ mlist a * n @ int.

(74)

Implementation

val rec length_aux [a] (accu: int, xs: mlist a) : int = match xs with..

| MNil ->..

accu..

| MCons ->..

length_aux (accu + 1, xs.tail)..

end

val length [a] (xs: mlist a) : int = length_aux (0, xs)

.

(75)

Implementation

| MNil ->..

accu..

| MCons ->..

end

. .

initially:

xs @ mlist a

(76)

Implementation

| MNil ->..

accu..

| MCons ->..

end

. .

upon entry into the first branch:

xs @ MNil

(77)

Implementation

| MNil ->..

accu..

| MCons ->..

end

. .

upon exit of the first branch:

xs @ MNil

(78)

Implementation

| MNil ->..

accu..

| MCons ->..

end

. .

upon exit of the first branch:

xs @ mlist a

(79)

Implementation

| MNil ->..

accu..

| MCons ->..

end

. .

upon entry into the second branch:

xs @ MCons { head = h; tail = t } h @ a

t @ mlist a

(80)

Implementation

| MNil ->..

accu..

| MCons ->..

end

. .

after the call, nothing has changed:

xs @ MCons { head = h; tail = t } h @ a

t @ mlist a

(81)

Implementation

| MNil ->..

accu..

| MCons ->..

end

. .

thus, by recombining:

xs @ MCons { head: a; tail: mlist a }

(82)

Implementation

| MNil ->..

accu..

| MCons ->..

end

. .

thus, by folding:

xs @ mlist a

(83)

Tail recursion versus iteration

The analysis of this code is surprisingly simple.

• This is atail-recursivefunction, i.e., a loop in disguise.

• As we go, there is alistahead of us and alist segmentbehind us.

• Ownership of the latter isimplicit, i.e., framed out.

Recursive reasoning, iterative execution.

(84)

Algebraic data structures

Melding mutable lists

(85)

Melding mutable lists (1/2)

val rec meld_aux [a]

(xs:.._MCons _{ _head: _a; _tail: _{mlist a} _},

consumes.._ys: mlist a) : () = match xs.tail with

| MNil ->..

xs.tail <- ys..

| MCons ->..

meld_aux (xs.tail, ys)..

end

.

(86)

Melding mutable lists (1/2)

| MNil ->..

xs.tail <- ys..

| MCons ->..

end

. .

xs is not consumed: at the end, it is still a valid non-empty list

(87)

Melding mutable lists (1/2)

| MNil ->..

xs.tail <- ys..

| MCons ->..

end

. .

at the end, ys is accessible through xs, hence must no longer be used directly

(88)

Melding mutable lists (1/2)

| MNil ->..

xs.tail <- ys..

| MCons ->..

end

. .

xs @ MCons { head: a; tail = t } t @ MNil

ys @ mlist a

(89)

Melding mutable lists (1/2)

| MNil ->..

xs.tail <- ys..

| MCons ->..

end

. .

xs @ MCons { head: a; tail = ys } t @ MNil

ys @ mlist a