Hindley-Milner elaboration in applicative style

(1)

Hindley-Milner elaboration in applicative style

Fran¸cois Pottier

(2)

This pearl presents

a (shamefully) simple solution

to a problem that has (gently) troubled me for ten years and whosestory begins even longer ago.

(3)

This pearl presents

(4)

This pearl presents

to a problem that has (gently) troubled me for ten years

and whosestory begins even longer ago.

(5)

This pearl presents

(6)

Part I

A STORY

(7)

The 1970s

Milner (1978) invents MLpolymorphism andtype inference.

(8)

The 1970s

Milner (1978) invents MLpolymorphism andtype inference.

(9)

Milner’s description

Milner publishes a declarative presentation,Algorithm W,

and an imperative one, Algorithm J.

Algorithm J maintains a

“current substitution” in a global variableE.

Both composesubstitutions produced by unification, and create “new”variables as needed.

(10)

Milner’s description

Milner publishes a declarative presentation,Algorithm W,

and an imperative one, Algorithm J.

(11)

Milner’s description

Milner publishes a declarative presentation,Algorithm W, and an imperative one, Algorithm J.

(12)

Milner’s description

(13)

Milner’s description

(14)

Milner’s description

(15)

The 1980s

Cardelli, Wand (1987) and others formulate type inference as a two-stage process: generating andsolving a conjunction of equations.

(16)

The 1980s

Cardelli, Wand (1987) and others formulate type inference as a two-stage process: generating andsolving a conjunction of equations.

(17)

Benefits

Higher-level thinking:

instead ofsubstitutions and composition, equationsand conjunction.

Greater modularity:

constraints and constraint solving as a library, constraint generation performed by theuser.

(18)

Limitations

New variables still created via aglobal side effect.

Polymorphic type inferencenot supported.

Algorithm J must solvethe constraints produced so far (it looks up E) before it canproducemore constraints.

(19)

The 1990s

Kirchner & Jouannaud (1990), R´emy (1992) and others explain “new” variables asexistential quantificationand constraint solving asrewriting. A necessary step on the road towards explainingpolymorphicinference.

(20)

The 1990s

Kirchner & Jouannaud (1990), R´emy (1992) and others explain “new”

variables asexistential quantificationand constraint solving asrewriting.

A necessary step on the road towards explainingpolymorphicinference.

(21)

The 2000s

Following Gustavsson and Svenningsson (2001), Didier R´emy and F.P. (2005) explain polymorphic type inference usingconstraint abstractions.

(22)

The 2000s

Following Gustavsson and Svenningsson (2001), Didier R´emy and F.P.

(2005) explain polymorphic type inference usingconstraint abstractions.

(23)

Constraints

Constraints offer a syntax for describing type inference problems.

τ ::=α|τ →τ |. . .

C ::=false|true|C∧C|τ =τ | ∃α.C (unification)

|letx=λα.C inC (abstraction)

|x τ (application)

The meaning of let-constraints is given by the law:

letx=λα.C₁ inC₂

≡ ∃α.C₁∧[λα.C1/x]C2

(24)

Constraint generation

A pure functionof a termt and a typeτ to a constraint Jt:τK. Jx:τK=x τ

Jλx.u:τK=∃α₁α2.

τ =α₁ →α₂∧

letx=λα.(α=α1)inJu:α2K

Jt1t2 :τK=∃α.(Jt1:α→τK∧Jt2:αK) Jletx=t₁ int₂ :τK=letx=λα.Jt₁ :αKinJt₂ :τK

(25)

Constraint solving

On paper, every constraint can berewritten step by step to either false or a solved form.

The imperative implementation, based on Huet’s unification algorithm and R´emy’s ranks, is efficient(McAllester, 2003).

(26)

Library (OCaml)

Abstract syntax for constraints:

t y p e v a r i a b l e

val f r e s h : v a r i a b l e s t r u c t u r e o p t i o n - > v a r i a b l e t y p e r a w c o =

| C T r u e

| C C o n j of r a w c o * r a w c o

| CEq of v a r i a b l e * v a r i a b l e

| C E x i s t of v a r i a b l e * r a w c o

| ...

Combinators that build constraints:

val t r u t h : r a w c o

val ( ^ & ) : r a w c o - > r a w c o - > r a w c o

val ( - -) : v a r i a b l e - > v a r i a b l e - > r a w c o val e x i s t : ( v a r i a b l e - > r a w c o ) - > r a w c o ...

(27)

User (OCaml)

The user defines constraint generation:

let rec h a s t y p e ( t : ML . t e r m ) ( w : v a r i a b l e ) : r a w c o

= m a t c h t w i t h

| ...

| ML . Abs ( x , u ) - >

e x i s t ( fun v1 - >

w - - - a r r o w v1 v2 ^&

def x v1 ( h a s t y p e u v2 ) )

)

| ...

let i s w e l l t y p e d ( t : ML . t e r m ) : r a w c o

= e x i s t ( fun w - > h a s t y p e t w )

(28)

Part II

A PROBLEM

(29)

A problem

Submitting aclosed ML term to the generator ...

yields aclosed constraint ... which the solver rewrites to ...

let b = if x = y then ... else ... in ...

∃α.(α=bool∧ ∃βγ.(. . .)) either false, or true.

(30)

A problem

yields aclosed constraint ...

which the solver rewrites to ...

∃α.(α =bool∧ ∃βγ.(. . .))

either false, or true.

(31)

A problem

∃α.(α =bool∧ ∃βγ.(. . .))

either false, or true.

(32)

A problem

∃α.(α =bool∧ ∃βγ.(. . .)) either false, or true.

(33)

A problem (OCaml)

The API offered by the library istoo simple:

val s o l v e : r a w c o - > b o o l (Ignoring type error diagnostics.)

The user has defined: val i s w e l l t y p e d : ML . t e r m - > r a w c o

There is no way of obtaining, say:

val e l a b o r a t e : ML . t e r m - > F . t e r m

which would be the front-end of atype-directed compiler.

(34)

A problem (OCaml)

val s o l v e : r a w c o - > b o o l

(Ignoring type error diagnostics.) The user has defined:

val i s w e l l t y p e d : ML . t e r m - > r a w c o

There is no way of obtaining, say:

(35)

A problem (OCaml)

val s o l v e : r a w c o - > b o o l

(Ignoring type error diagnostics.) The user has defined:

val i s w e l l t y p e d : ML . t e r m - > r a w c o There is no way of obtaining, say:

(36)

Question

Can one performelaboration

without compromising themodularity andelegance of the constraint-based approach?

(37)

Part III

A SOLUTION

(38)

A low-level solution

The generator could produce a pair of a constraintand

a template for an elaborated term, sharingmutable placeholders for evidence, so that, after the constraint issolved,

the template can be“solidified”into an elaborated term.

(39)

Library, low-level (OCaml)

Constraints already contain mutable placeholders for evidence:

... | C E x i s t of v a r i a b l e * r a w c o | ...

More placeholders (not shown) required to deal with polymorphism.

Let the library offer a type decoder, which can be invokedaftersolving:

t y p e d e c o d e r = v a r i a b l e - > ty val n e w _ d e c o d e r : u n i t - > d e c o d e r ...

(40)

User (OCaml)

The user could write:

val h a s t y p e :

ML . t e r m - > v a r i a b l e - > r a w c o * F . t e m p l a t e val s o l i d i f y :

F . t e m p l a t e - > F . t e r m where:

the constraint and the template sharevariables,

solidifyuses a type decoder to replace these variables with types.

(41)

Why I not am happy with stopping here

This approach is in three stages: generation, solving, solidification.

Each user construct is dealt withtwice,in stages 1 and 3.

This approachexposes evidenceto the user.

Evidence is mutable and involves names and binders.

One needs an intermediate representationF.template, or one must polluteF.term.

(42)

A wish

Even though stages 1 and 3 must beexecutedseparately, the user would prefer todescribethem in a unified manner.

(43)

A dream

If the user could somehow (magically?)

construct the constraint, and “simultaneously”

query the solver for thefinal (decoded) witness for a variable then she would be able to perform elaboration in one swoop:

val e l a b o r a t e : ML . t e r m - > F . t e r m and evidence would not need to be exposed.

(44)

The idea

Give the user theillusionthat she can use the solver in this manner.

Give her a DSL to expresscomputationsthat:

emit constraintsand read their solutions.

It turns out that this DSL is just our good oldconstraints,

extended with a mapcombinator.

(45)

The idea

Give the user theillusionthat she can use the solver in this manner.

Give her a DSL to expresscomputationsthat:

emit constraintsand read their solutions.

It turns out that this DSL is just our good oldconstraints,

extended with a mapcombinator.

(46)

Library, high-level (OCaml)

Solving/evaluating a constraintproduces a result.

t y p e ’ a co

val s o l v e : ’ a co - > ’ a val p u r e : ’ a - > ’ a co

val ( ^ & ) : ’ a co - > ’ b co - > ( ’ a * ’ b ) co val map : ( ’ a - > ’ b ) - > ’ a co - > ’ b co val ( - -): v a r i a b l e - > v a r i a b l e - > u n i t co val e x i s t : ( v a r i a b l e - > ’ a co ) - > ( ty * ’ a ) co ...

E.g., evaluating∃α.C yields apairof a decoded type (thewitness forα) and the value ofC.

(47)

Library, high-level (OCaml)

This is implementedon top ofthe earlier, low-level library.

t y p e env = d e c o d e r t y p e ’ a co =

r a w c o * ( env - > ’ a )

A constraint/computation is a pair of

I a raw constraint, which contains mutable evidence;

I a continuation,which reads this evidenceafterthe solver has run.

(48)

Library, high-level (OCaml)

The implementation is quasi-trivial.

let e x i s t f =

let v = f r e s h N o n e in let rc , k = f v in C E x i s t ( v , rc ) , fun env - >

let d e c o d e = env in ( d e c o d e v , k env )

(49)

User (OCaml)

The user defines inference/elaboration inone inductive function:

let rec h a s t y p e t w : F.term co

= m a t c h t w i t h

| ...

| ML . Abs ( x , u ) - >

w - - - a r r o w v1 v2 ^&

def x v1 ( h a s t y p e u v2 ) )

) <$$> fun (ty1, (ty2, ((), u’))) ->

F.Abs (x, ty1, u’)

| ...

The (final, decoded) typety1 of x seems to bemagically available.

(50)

Remarks

Elaboration from ML to System F in the paper (and online).

The type’a co forms an applicative functor,not a monad.

(51)

Part IV

Conclusion

(52)

Conclusion

I a simple idea, really

I just icing on the cake

I modularity, elegance, performance

I usable in other settings? e.g. higher-order pattern unification?

(53)

Thank you

http://gallium.inria.fr/~fpottier/inferno/

No mutable state was exposed in the making of this library.