[PPT] - Existential Types for Imperative Languages Dan Grossman Cornell PowerPoint Presentation

SLIDE 1

Existential Types for Imperative Languages

Dan Grossman Cornell University

Eleventh European Symposium on Programming April 2002

SLIDE 2

8 April 2002 Existential Types for Imperative Languages 2

Designing safe languages

To design a strong-typed language:

1. Draw on acquired knowledge of well-

behaved features

2. Model the parts you’re uncomfortable with

(in practice, a simplification)

3. Hope/argue that the model captured

everything interesting, so the language is type-safe

SLIDE 3

8 April 2002 Existential Types for Imperative Languages 3

But…

Sometimes you are wrong due to a new

combination of features

You fix it
You worry enough to model the fix
You add to acquired knowledge
Today’s combination: existential types,

aliasing, and mutation

SLIDE 4

8 April 2002 Existential Types for Imperative Languages 4

How the story goes…

Existential types in a safe low-level language

– why – features (mutation, aliasing)

The problem
The solutions
Some non-problems
Related work

SLIDE 5

8 April 2002 Existential Types for Imperative Languages 5

Existential types

Existential types (∃ α . τ) hide types’ identities

while establishing equalities, e.g., ∃ α. { zero: α succ: α → α cmp: α → α → bool }

That is, they describe abstract data types
The standard tool for modeling data-hiding

constructs (closures, objects)

SLIDE 6

8 April 2002 Existential Types for Imperative Languages 6

Low-level languages want ∃

Cyclone (this work’s context) is a safe language at

the C level of abstraction

Major goal: expose data representation (no hidden

fields, tags, environments, ...)

Don’t provide closures/objects; give programmers a

powerful type system struct IntIntFn { ∃ α. int (f)(int, α); α env; }; C “call-backs” use void; we use ∃

SLIDE 7

8 April 2002 Existential Types for Imperative Languages 7

Normal ∃ feature: Construction

int add (int a, int b) {return a+b; } int addp(int a, char* b) {return a+*b;} struct IntIntFn x1 = IntIntFn(add, 37); struct IntIntFn x2 = IntIntFn(addp,"a");

Compile-time: check for appropriate witness type
Type is just struct IntIntFn
Run-time: create / initialize (no witness type)

struct IntIntFn { ∃ α. int (*f)(int, α); α env; };

SLIDE 8

8 April 2002 Existential Types for Imperative Languages 8

Normal ∃ feature: Destruction

struct IntIntFn { ∃ α. int (f)(int, α); α env; }; Destruction via pattern matching: void apply(struct IntIntFn x) { let IntIntFn{<β> .f=fn, .env=ev} = x; // ev : β, fn : int(f)(int,β) fn(42,ev); } Clients use the data without knowing the type

SLIDE 9

8 April 2002 Existential Types for Imperative Languages 9

Low-level feature: Mutation

Mutation, changing witness type

struct IntIntFn fn1 = f(); struct IntIntFn fn2 = g(); fn1 = fn2; // record-copy

Orthogonality encourages this feature
Useful for registering new call-backs without

allocating new memory

Now memory is not type-invariant!

SLIDE 10

8 April 2002 Existential Types for Imperative Languages 10

Low-level feature: Address-of field

Let client update fields of an existential package

– access only through pattern-matching – variable pattern copies fields

A reference pattern binds to the field’s address:

void apply2(struct IntIntFn x) { let IntIntFn{<β> .f=fn, .env=ev} = x; // ev : β, fn : int(f)(int,β) fn(42,ev); } C uses &x.env; we use a reference pattern

SLIDE 11

8 April 2002 Existential Types for Imperative Languages 11

More on reference patterns

Orthogonality: already allowed in Cyclone’s
ther patterns (e.g., tagged-union fields)
Can be useful for existential types:

struct Pr {∃ α. α fst; α snd; }; ∀α. void swap(α* x, α* y); void swapPr(struct Pr pr) { let Pr{<β> .fst=a, .env=b} = pr; swap(a,b); }

SLIDE 12

8 April 2002 Existential Types for Imperative Languages 12

Summary of features

struct definition can bind existential type

variables

construction, destruction traditional
mutation via struct assignment
reference patterns for aliasing

A nice adaptation of advanced type-systems to a “safe C” setting?

SLIDE 13

8 April 2002 Existential Types for Imperative Languages 13

Explaining the problem

Violation of type safety
Two solutions (restrictions)
Some non-problems

SLIDE 14

8 April 2002 Existential Types for Imperative Languages 14

Oops!

struct T { ∃ α. void (f)(int, α); α env;}; void ignore(int x, int y) {} void assign(int x, int p) { p = x; } void f(int ptr) { struct T pkg1 = T(ignore, 0xABCD);//α=int struct T pkg2 = T(assign, ptr); //α=int* let T{<β> .f=fn, .env=ev} = pkg2; //alias pkg2 = pkg1; //mutation fn(37, ev); //write 37 to 0xABCD }

SLIDE 15

8 April 2002 Existential Types for Imperative Languages 15

With pictures…

assign pkg1 pkg2 ignore 0xABCD let T{<β> .f=fn, .env=*ev} = pkg2; //alias assign pkg1 pkg2 ignore 0xABCD assign fn ev

SLIDE 16

8 April 2002 Existential Types for Imperative Languages 16

With pictures…

assign pkg1 pkg2 ignore 0xABCD assign fn ev pkg2 = pkg1; //mutation pkg2 ignore 0xABCD assign pkg1 ignore 0xABCD fn ev

SLIDE 17

8 April 2002 Existential Types for Imperative Languages 17

With pictures…

pkg1 pkg2 ignore 0xABCD ignore 0xABCD assign fn ev fn(37, ev); //write 37 to 0xABCD call assign with 0xABCD for p, the pointer: void assign(int x, int p) {*p = x;}

SLIDE 18

8 April 2002 Existential Types for Imperative Languages 18

What happened?

let T{<β> .f=fn, .env=ev} = pkg2; //alias pkg2 = pkg1; //mutation fn(37, ev); //write 37 to 0xABCD 1. β establishes a compile-time equality relating types

f fn (void(*f)(int,β)) and ev (β*)

2. mutation makes this equality false 3. safety of call needs the equality we must rule out this program…

SLIDE 19

8 April 2002 Existential Types for Imperative Languages 19

Two solutions

Solution #1:

Reference patterns do not match against fields of existential packages Note: Other reference patterns still allowed ⇒ cannot create the type equality

Solution #2:

Type of assignment cannot be an existential type (or have a field of existential type) Note: pointers to existentials are no problem ⇒ restores memory type-invariance

SLIDE 20

8 April 2002 Existential Types for Imperative Languages 20

Independent and easy

Either solution is easy to implement
They are independent: A language can have

two styles of existential types, one for each restriction

Cyclone takes solution #1 (no reference

patterns for existential fields), making it a safe language without type-invariance of memory!

SLIDE 21

8 April 2002 Existential Types for Imperative Languages 21

Are the solutions sufficient (correct)?

The paper develops a small formal language

and proves type safety

Highlights:

– Both solutions – C-style memory (flattened record values) – C-style lvalue/rvalue distinction – Memory invariant includes novel “if a reference pattern is for a field, then that field never changes type”

SLIDE 22

8 April 2002 Existential Types for Imperative Languages 22

Non-problem: Pointers to witnesses

struct T2 { ∃ α. void (f)(int, α); α env; }; … let T2{<β> .f=fn, .env=ev} = pkg2; pkg2 = pkg1; … pkg2 assign assign fn ev

SLIDE 23

8 April 2002 Existential Types for Imperative Languages 23

Non-problem: Pointers to packages

struct T * p = &pkg1; p = &pkg2; assign pkg1 pkg2 ignore 0xABCD p Aliases are fine. Aliases at the “unpacked type” are not.

SLIDE 24

8 April 2002 Existential Types for Imperative Languages 24

Related work

Existential types:

– seminal use [Mitchell/Plotkin 1988] – closure/object encodings [Bruce et al, Minimade et al, …] – first-class types in Haskell [Läufer] None incorporate mutation

Safe low-level languages with ∃

– Typed Assembly Language [Morrisett et al] – Xanadu [Xi], uses ∃ over ints (so does Cyclone) None have reference patterns or similar

Linear types, e.g. Vault [DeLine, Fähndrich]

No aliases, destruction destroys the package

SLIDE 25

8 April 2002 Existential Types for Imperative Languages 25

Polymorphic references — related?

Well-known in ML that you must not give

ref [] the type ∀α. α list ref

Unsoundness involves mutation and aliasing
Suggests the problem is dual, and there are

similarities, but it’s unclear

ML has memory type-invariance,

unlike Cyclone

SLIDE 26

8 April 2002 Existential Types for Imperative Languages 26

Summary

Existential types are the way to have data-

hiding in a safe low-level language

But type variables, mutation, and aliasing

signal danger

Developed two independent, simple

restrictions that suffice for type safety

Rigorous proof to help us think we’ve really

fixed the problem

New acquired knowledge to avoid future mistakes

SLIDE 27

8 April 2002 Existential Types for Imperative Languages 27

[End of Presentation -- Some “backup slides” follow]

SLIDE 28

8 April 2002 Existential Types for Imperative Languages 28

Future work — Threads

For very similar reasons, threads require:

– atomic assignment (witness-change) of existential packages – atomic pattern-matching (destruction) of existential packages

Else pattern-match could get fields with

different witness types, violating type equality

Future: Type system will enforce a

programmer-controlled locking system

SLIDE 29

8 April 2002 Existential Types for Imperative Languages 29

What is a good witness?

Without (hidden) run-time types, we must know the size of (values of) abstract types struct IntIntFn { ∃ α. int (f)(int, α); α env; }; α must be int or pointer struct IntIntFn { ∃ α. int (f)(int, α); α env; }; α can be any type Interesting & orthogonal issue — come back tomorrow

Existential Types for Imperative Languages

Dan Grossman Cornell University

Eleventh European Symposium on Programming April 2002

Designing safe languages

To design a strong-typed language:

behaved features

(in practice, a simplification)

everything interesting, so the language is type-safe

But…

combination of features

aliasing, and mutation

How the story goes…

– why – features (mutation, aliasing)

Existential types

while establishing equalities, e.g., ∃ α. { zero: α succ: α → α cmp: α → α → bool }

constructs (closures, objects)

Low-level languages want ∃

the C level of abstraction

fields, tags, environments, ...)

powerful type system struct IntIntFn { ∃ α. int (*f)(int, α); α env; }; C “call-backs” use void*; we use ∃

Normal ∃ feature: Construction

int add (int a, int b) {return a+b; } int addp(int a, char* b) {return a+*b;} struct IntIntFn x1 = IntIntFn(add, 37); struct IntIntFn x2 = IntIntFn(addp,"a");

struct IntIntFn { ∃ α. int (*f)(int, α); α env; };

Normal ∃ feature: Destruction

struct IntIntFn { ∃ α. int (*f)(int, α); α env; }; Destruction via pattern matching: void apply(struct IntIntFn x) { let IntIntFn{<β> .f=fn, .env=ev} = x; // ev : β, fn : int(*f)(int,β) fn(42,ev); } Clients use the data without knowing the type

Low-level feature: Mutation

struct IntIntFn fn1 = f(); struct IntIntFn fn2 = g(); fn1 = fn2; // record-copy

allocating new memory

Low-level feature: Address-of field

– access only through pattern-matching – variable pattern copies fields

void apply2(struct IntIntFn x) { let IntIntFn{<β> .f=fn, .env=*ev} = x; // ev : β*, fn : int(*f)(int,β) fn(42,*ev); } C uses &x.env; we use a reference pattern

More on reference patterns

struct Pr {∃ α. α fst; α snd; }; ∀α. void swap(α* x, α* y); void swapPr(struct Pr pr) { let Pr{<β> .fst=*a, .env=*b} = pr; swap(a,b); }

Summary of features

variables

A nice adaptation of advanced type-systems to a “safe C” setting?

Explaining the problem

Oops!

With pictures…

assign pkg1 pkg2 ignore 0xABCD let T{<β> .f=fn, .env=*ev} = pkg2; //alias assign pkg1 pkg2 ignore 0xABCD assign fn ev

With pictures…

assign pkg1 pkg2 ignore 0xABCD assign fn ev pkg2 = pkg1; //mutation pkg2 ignore 0xABCD assign pkg1 ignore 0xABCD fn ev

With pictures…

pkg1 pkg2 ignore 0xABCD ignore 0xABCD assign fn ev fn(37, *ev); //write 37 to 0xABCD call assign with 0xABCD for p, the pointer: void assign(int x, int* p) {*p = x;}

What happened?

let T{<β> .f=fn, .env=*ev} = pkg2; //alias pkg2 = pkg1; //mutation fn(37, *ev); //write 37 to 0xABCD 1. β establishes a compile-time equality relating types

2. mutation makes this equality false 3. safety of call needs the equality we must rule out this program…

Two solutions

Reference patterns do not match against fields of existential packages Note: Other reference patterns still allowed ⇒ cannot create the type equality

Type of assignment cannot be an existential type (or have a field of existential type) Note: pointers to existentials are no problem ⇒ restores memory type-invariance

Independent and easy

two styles of existential types, one for each restriction

patterns for existential fields), making it a safe language without type-invariance of memory!

Are the solutions sufficient (correct)?

and proves type safety

– Both solutions – C-style memory (flattened record values) – C-style lvalue/rvalue distinction – Memory invariant includes novel “if a reference pattern is for a field, then that field never changes type”

Non-problem: Pointers to witnesses

struct T2 { ∃ α. void (*f)(int, α); α* env; }; … let T2{<β> .f=fn, .env=ev} = pkg2; pkg2 = pkg1; … pkg2 assign assign fn ev

Non-problem: Pointers to packages

struct T * p = &pkg1; p = &pkg2; assign pkg1 pkg2 ignore 0xABCD p Aliases are fine. Aliases at the “unpacked type” are not.

Related work

– seminal use [Mitchell/Plotkin 1988] – closure/object encodings [Bruce et al, Minimade et al, …] – first-class types in Haskell [Läufer] None incorporate mutation

– Typed Assembly Language [Morrisett et al] – Xanadu [Xi], uses ∃ over ints (so does Cyclone) None have reference patterns or similar

No aliases, destruction destroys the package

Polymorphic references — related?

ref [] the type ∀α. α list ref

similarities, but it’s unclear

unlike Cyclone

Summary

hiding in a safe low-level language

signal danger

restrictions that suffice for type safety

fixed the problem

New acquired knowledge to avoid future mistakes

[End of Presentation -- Some “backup slides” follow]

Future work — Threads

– atomic assignment (witness-change) of existential packages – atomic pattern-matching (destruction) of existential packages

different witness types, violating type equality

programmer-controlled locking system

What is a good witness?

powerful type system struct IntIntFn { ∃ α. int (f)(int, α); α env; }; C “call-backs” use void; we use ∃

struct IntIntFn { ∃ α. int (f)(int, α); α env; }; Destruction via pattern matching: void apply(struct IntIntFn x) { let IntIntFn{<β> .f=fn, .env=ev} = x; // ev : β, fn : int(f)(int,β) fn(42,ev); } Clients use the data without knowing the type

void apply2(struct IntIntFn x) { let IntIntFn{<β> .f=fn, .env=ev} = x; // ev : β, fn : int(f)(int,β) fn(42,ev); } C uses &x.env; we use a reference pattern

struct Pr {∃ α. α fst; α snd; }; ∀α. void swap(α* x, α* y); void swapPr(struct Pr pr) { let Pr{<β> .fst=a, .env=b} = pr; swap(a,b); }

pkg1 pkg2 ignore 0xABCD ignore 0xABCD assign fn ev fn(37, ev); //write 37 to 0xABCD call assign with 0xABCD for p, the pointer: void assign(int x, int p) {*p = x;}

let T{<β> .f=fn, .env=ev} = pkg2; //alias pkg2 = pkg1; //mutation fn(37, ev); //write 37 to 0xABCD 1. β establishes a compile-time equality relating types

struct T2 { ∃ α. void (f)(int, α); α env; }; … let T2{<β> .f=fn, .env=ev} = pkg2; pkg2 = pkg1; … pkg2 assign assign fn ev

Without (hidden) run-time types, we must know the size of (values of) abstract types struct IntIntFn { ∃ α. int (f)(int, α); α env; }; α must be int or pointer struct IntIntFn { ∃ α. int (f)(int, α); α env; }; α can be any type Interesting & orthogonal issue — come back tomorrow