[PDF] - In tro duction to F unctional Programming: Lecture 3 1 In PDF Document

SLIDE 1 In tro duction to F unctional Programming: Lecture 3 1 In tro duction to F unctional Programming John Harrison Univ ersit y

f

Cam bridge Lecture 3 ML's t yp e system T

pics

co v ered:

Wh

y t yp es?

Approac

hes to t yping

Basic

t yp es.

P
lymorphism.
ML

t yp ec hec king.

Equalit

y t yp es John Harrison Univ ersit y

f

Cam bridge, 20 Jan uary 1998

SLIDE 2 In tro duction to F unctional Programming: Lecture 3 2 Logical reasons for t yp es T yp es help us rule

ut

certain programs that don't seem to mak e sense. Is it reasonable to apply a function to itself, as in f f? It mak es some sense for functions lik e the iden tit y fn x => x

r

constan t functions fn x => y. But in general it lo

ks

v ery suspicious. This sort

f

self-application can lead to inconsistencies in formal logics designed to pro vide a foundation for mathematics. F

r

example, Russell's parado x considers fx j x 62 xg, the set

f

all sets that are not mem b ers

f

themselv es. T

a

v

id

this, Russell in tro duced a system

f

t yp es. T yp e theory is no w seen as an alternative to set theory as a foundation. There are in teresting links b et w een t yp e theory and programming. John Harrison Univ ersit y

f

Cam bridge, 20 Jan uary 1998

SLIDE 3 In tro duction to F unctional Programming: Lecture 3 3 Programming reasons for t yp es T yp es w ere in tro duced in programming for a mixture

f

reasons. W e can (at least in retrosp ect) see the follo wing adv an tages:

They

can help the computer to generate more ecien t co de, and use space more eectiv ely .

They

serv e as a kind

f

`sanit y c hec k' for programs, catc hing a lot

f

programming errors b efore execution.

They

can serv e as do cumen tation for p eople.

They

can help with data hiding and mo dularization. A t the same time, some programmers nd them an irksome restriction. Ho w can w e ac hiev e the b est balance? John Harrison Univ ersit y

f

Cam bridge, 20 Jan uary 1998

SLIDE 4 In tro duction to F unctional Programming: Lecture 3 4 Dieren t t yping metho ds W e can distinguish b et w een

Strong

t yping, as in Mo dula-3, where t yp es m ust matc h up exactly .

W

eak t yping, as in C, where greater latitude is allo w ed (e.g. an argumen t

f

t yp e int to a function exp ecting a float). and also b et w een

Static

t yping, as in F OR TRAN, whic h happ ens during compilation

Dynamic

t yping, as in LISP , whic h happ ens during execution. ML is statically and strongly t yp ed. A t the same time, a feature called p

lymorphism

giv es man y b enets

f

w eak

r

dynamic t yping. John Harrison Univ ersit y

f

Cam bridge, 20 Jan uary 1998

SLIDE 5 In tro duction to F unctional Programming: Lecture 3 5 Basic t yp es The primitiv e t yp es in ML include:

T

yp e unit, a 1-elemen t t yp e, whose

nly

elemen t is written ().

T

yp e bool, a 2-elemen t t yp e whose elemen ts are written true and false.

T

yp e int, a subset

f

the p

sitiv

e and negativ e in tegers, e.g. 6 and ~11.

T

yp e real,

ating

p

in

t n um b ers, written e.g. 1.0 and 3.1415926.

T

yp e string, whic h corresp

nds

to sequences

f

c haracters, written "like this". These can b e put together using t yp e constructors, including the function constructor

>

and the Cartesian pro duct constructor *. W e will see ho w to dene new t yp es and t yp e constructors later. John Harrison Univ ersit y

f

Cam bridge, 20 Jan uary 1998

SLIDE 6 In tro duction to F unctional Programming: Lecture 3 6 P

lymorphism

Some functions can ha v e v arious dieren t t yp es | p

lymorphism.

W e distinguish b et w een:

T

rue (`parametric') p

lymorphism,

where all the p

ssible

t yp es for an expression are instances

f

some sc hematic t yp e, and all instances

f

that sc hema are p

ssible

t yp es. F

r

example, fn x => x can ha v e an y t yp e

f

the form

>

, e.g. int

>

int

r

bool

>

bool but not int

>

real.

Ad

ho c p

lymorphism,
r
verlo

ading, where this isn't so. The addition

p

eration in fn x => 1 + x and fn x => 1.0 + x has t yp es int * int

>

int and real * real

>

real resp ectiv ely , but it can't ha v e t yp e bool * bool

>

bool. ML has

v

erloading, but

nly

for a few sp ecial cases, and w e prefer to ignore it. W e'll concen trate

n

(parametric) p

lymorphism.

John Harrison Univ ersit y

f

Cam bridge, 20 Jan uary 1998

SLIDE 7 In tro duction to F unctional Programming: Lecture 3 7 T yp e v ariables In

rder

to express p

lymorphism,

ML allo ws t yp es to con tain typ e variables. These are written 'a, 'b etc., ASCI I appro ximations to

and
.

If an expression has a t yp e in v

lving
then

it can also b e giv en an y t yp e that results from consisten tly replacing

b

y another t yp e (whic h ma y itself in v

lv

e t yp e v ariables). Let's sa y that a t yp e

is

more general than

,

and write

,

when w e can substitute t yp es for t yp e v ariables in

and

get

.

F

r

example:

bool
(

!

)
(int

! int ) ( !

)

6 (int ! bool ) ( !

)
(

!

)

( !

)

6

John

Harrison Univ ersit y

f

Cam bridge, 20 Jan uary 1998

SLIDE 8 In tro duction to F unctional Programming: Lecture 3 8 Most general t yp es Ev ery expression in ML that has a t yp e has a most general t yp e. This w as rst pro v ed in a similar con text b y Hindley , and for the exact setup here b y Milner. What's more, there is an algorithm for nding the most general t yp e

f

an y expression, ev en if it con tains no t yp e information at all. ML implemen tations use this algorithm. Therefore it is nev er necessary in ML to write do wn a t yp e. All t yping is implicit. Th us, the ML t yp e system is m uc h less irksome than in man y languages lik e Mo dula-3. W e nev er ha v e to sp ecify t yp es explicitly and w e can

ften

re-use the same co de with dieren t t yp es: the compiler will w

rk

ev erything

ut

for us. John Harrison Univ ersit y

f

Cam bridge, 20 Jan uary 1998

SLIDE 9 In tro duction to F unctional Programming: Lecture 3 9 ML t yp e inference (1) R

ughly

sp e aking, here's ho w ML's t yp e inference w

rks.

Using this metho d y

u

can t yp ec hec k ML expressions y

urself,

though it's rather lab

rious

and with some exp erience it b ecomes m uc h easier. W e'll use as an example: fn a => (fn f => fn x => f x) (fn x => x) First, attac h distinct t yp e v ariables to distinct v ariables in the expression, and the appropriate t yp es to previously dened constan ts, p erhaps themselv es p

lymorphic.

Dieren t t yp e v ariables m ust b e used for distinct instances

f

p

lymorphic

constan ts. Note that v ariables lik e x in fn x => ha v e a limited scop e, and

utside

that scop e instances

f

x are really separate v ariables. W e get fn (a: ) => (fn (f: ) => fn (x: ) => (f: ) (x: )) (fn (x: ) => (x: )). John Harrison Univ ersit y

f

Cam bridge, 20 Jan uary 1998

SLIDE 10 In tro duction to F unctional Programming: Lecture 3 10 ML t yp e inference (2) No w an application

f

a function to an argumen t f x can

nly

b e w ell-t yp ed if f :

!
and

x :

for

some

and
.

In this case, (f x) :

.

An expression fn (x: ) => E: has t yp e

!
.

Using these facts, w e can nd relations among the t yp e v ariables. Essen tially , w e get a series

f

sim ultaneous equations, and use them to eliminate some unkno wns. The remaining unkno wns, if an y , parametrize the nal p

lymorphic

t yp e. If the t yp es can't b e matc hed up,

r

some t yp e v ariable has to b e equal to some comp

site

t yp e con taining itself, then t yp ec hec king fails. Another w a y

f

lo

king

at it is as a case

f

unic ation. John Harrison Univ ersit y

f

Cam bridge, 20 Jan uary 1998

SLIDE 11 In tro duction to F unctional Programming: Lecture 3 11 ML t yp e inference (3) First, w e ha v e an application (f: ) (x: ). F

r

this to b e w ell-t yp ed, w e m ust ha v e, for some

that
=
!

. No w (fn f => fn x => f x):( ! ) ! ( ! ) and this is applied to (fn x => x): !

So

w e m ust ha v e ( ! ) = ( !

)

and so

=
and
=
,

and the whole expression has t yp e

!

( !

).

It do esn't matter ho w w e name the t yp e v ariables no w, so w e can call it

!

( !

).

This is the end result

f

t yp e c hec king. John Harrison Univ ersit y

f

Cam bridge, 20 Jan uary 1998

SLIDE 12 In tro duction to F unctional Programming: Lecture 3 12 Let p

lymorphism

Recall that w e can ha v e lo cal bindings, e.g. using let val v = E in E' end. W e need to sa y ho w to t yp ec hec k this. W e can regard it as synon ymous with (fn v => E') E, but then follo wing the previous rules fails to giv e

ne

v ery imp

rtan

t prop ert y: If v is b

und

to something p

lymorphic,

w e w an t to allo w it to b e instan tiated to m ultiple instances inside, e.g. let val I = fn x => x in if I true then I 1 else end; One can t yp ec hec k suc h expressions simply b y substituting its denition for the b

und

v ariable. This is not v ery ecien t, but is satisfactory in principle. Of course,

ne

m ust also c hec k that the b

und

expression is itself w ell-t yp ed, in case it isn't used in the b

dy

. John Harrison Univ ersit y

f

Cam bridge, 20 Jan uary 1998

SLIDE 13 In tro duction to F unctional Programming: Lecture 3 13 T yp e preserv ation In ML, the phases

f

typ e che cking and evaluation are separate, the former completed `statically' b efore ev aluation b egins. F

r

this to w

rk,

it's essen tial that ev aluation

f

w ell-t yp ed expressions cannot giv e rise to ill-t yp ed expressions, i.e. that (static) t yping and (dynamic) ev aluation don't in terfere with eac h

ther.

This prop ert y is called typ e pr eservation. The main step in ev aluation is the transition from (fn x => t[x]) u to t[u]. It's not hard to see, follo wing

ur

rules, that x and u m ust ha v e the same t yp es at the

utset,

so this preserv es t yp eabilit y . The rev erse is not true, e.g. (fn a => fn b => b) (fn x => x x) is un t yp eable ev en though fn b => b is t yp eable. John Harrison Univ ersit y

f

Cam bridge, 20 Jan uary 1998

SLIDE 14 In tro duction to F unctional Programming: Lecture 3 14 P athologies

f

t yp ec hec king In all

ur

examples, the system v ery quic kly infers a most general t yp e for eac h expression, and the t yp e is simple. This usually happ ens in practice, but there are pathological cases, e.g. the follo wing example due to Mairson: fn a => let fun pair x y = fn z => z x y val x1 = fn y => pair y y val x2 = fn y => x1(x1 y) val x3 = fn y => x2(x2 y) val x4 = fn y => x3(x3 y) val x5 = fn y => x4(x4 y) in x5 (fn z => z) end; The t yp e

f

this expression tak es ab

ut

a min ute to calculate, and when prin ted

ut

tak es 50,000 lines. Don't try this at home. John Harrison Univ ersit y

f

Cam bridge, 20 Jan uary 1998

SLIDE 15 In tro duction to F unctional Programming: Lecture 3 15 Equalit y t yp es Sometimes

ne

sees instead

f

'a a t yp e v ariable ''a. These sometimes arise when using the built-in equalit y

p

eration inside an expression. Equalit y is not completely p

lymorphic:
ne

cannot compare functions,

r

expressions built up from functions. While this migh t seem to go against the functional programming philosoph y , extensional equalit y

f

functions is not computable. The t yp e system is used to reect this.

(fn

x => x) = (fn x => x); ! Toplevel input: ! (fn x => x) = (fn x => x); ! ^^^^^^ ! Type clash: match rule

f

type ! 'a

>

'b ! cannot have equality type ''c John Harrison Univ ersit y

f

Cam bridge, 20 Jan uary 1998