Once Upon a Polymorphic Type CAMBRIDGE Keith Wansbrough Computer - - PowerPoint PPT Presentation

UNIVERSITY OF

CAMBRIDGE

Once Upon a Polymorphic Type

Keith Wansbrough

Computer Laboratory University of Cambridge kw217@cl.cam.ac.uk http://www.cl.cam.ac.uk/users/kw217/

Simon Peyton Jones

Microsoft Research Cambridge

20 January, 1999

Once Upon a Polymorphic Type (POPL’99) 1 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Why usage analysis? Problem:

Solutions:

Once Upon a Polymorphic Type (POPL’99) 2 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Lazy evaluation

Heap, before and after:

unnecessary update Unnecessary updates mean excess memory traffic.

✘

Once Upon a Polymorphic Type (POPL’99) 3 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

The goal Identify variables and subexpressions that will be evaluated at most once.

Once Upon a Polymorphic Type (POPL’99) 4 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Usage analysis enables other optimisations too Inlining:

• y

• f

• y

• f

Here

constructing a thunk for

Always valid, but serious slow-down if lambda applied more than

• nce; ‘work-safe’ if lambda applied (used) at most once.

Several other optimisations can similarly benefit from usage information.

Once Upon a Polymorphic Type (POPL’99) 5 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Plan of attack

Usage inference provides additional information at Core level to guide optimising transformations and code generation.

Once Upon a Polymorphic Type (POPL’99) 6 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

How do we do it? It seems that we should simply be able to count syntactic

• ccurrences. But this is not enough.

• x

Here

call to

The usage of

Once Upon a Polymorphic Type (POPL’99) 7 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Types We represent usage information in the types of expressions:

• x

• x

• y

Once Upon a Polymorphic Type (POPL’99) 8 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Type syntax Types

• ::=

• k

(unannotated)

• 1

• 2

• j
• Types
• ::=
• u

(annotated) Usages

for example,

• (List

• !.

Once Upon a Polymorphic Type (POPL’99) 9 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Type rules Type judgements are of the form

• `

• context

expression type For example, the rule for addition:

• `

• `

• `

Once Upon a Polymorphic Type (POPL’99) 10 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Type rules for UsageSP – 1: Functions

• 1

• 2
• c

(multiple occurrence)

• c

• u

for all

• (free variables)

• `
• x

• 1

• 2

• c

• x

Here

• c

• c

• c

Once Upon a Polymorphic Type (POPL’99) 11 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Three design decisions

– Should type variables be annotated or unannotated? What is the usage of a type abstraction?

– How should constructor applications be typed?

– How can we avoid equating usages of all arguments to a common function?

Once Upon a Polymorphic Type (POPL’99) 12 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Design decision 1: Type polymorphism

– Should type arguments be annotated or unannotated?

• !

• ;
• )

• r

• 1

• ;
• )

?

– Given

• `

• u, what is

• :

Once Upon a Polymorphic Type (POPL’99) 13 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Type rules for UsageSP – 3: Type polymorphism Type abstractions and applications are treated as ‘transparent’ for the purposes of usage annotation, since

• perationally they have no significance. These rules simply lift and

lower the usage annotation.

• `

• u

• `
• :

• )

• `

• 2

• `

• 1

• 1

Once Upon a Polymorphic Type (POPL’99) 14 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Design decision 2: Data structures Our language features user-defined algebraic data types such as

• =

• )
• (T

• )

• How should these be typed?

Once Upon a Polymorphic Type (POPL’99) 15 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Data structures: First attempt If we treat data constructors as normal functions, what usages should we place on the arguments and result?

• )

• )

• )

To make

✘

inaccurate. The usages

• n the constructor itself.

Once Upon a Polymorphic Type (POPL’99) 16 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

The tantalising opportunity

• x

• y

• f

Each component of the pair returned by

How can we propagate this information from the usage site (the

expression) to the construction site in

Once Upon a Polymorphic Type (POPL’99) 17 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Data structure usage propagation – 1 We propagate usage information through the type of the constructed data. There are a number of alternatives here.

• =

• data

• =

• )
• (T

• )

• 1. Give usage annotations for each constructor argument explicitly

in the type:

(typical application)

(effective type) This is the most general approach, but it is expensive.

Once Upon a Polymorphic Type (POPL’99) 18 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Data structure usage propagation – 2

• 2. Attach usage annotations to each type argument [BS96]:

• 3. Assume all constructor arguments will be used more than once.

Once Upon a Polymorphic Type (POPL’99) 19 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Data structure usage propagation – 3

• 4. Identify usage annotations for each constructor argument with

the overall usage of the constructed data.

We choose this solution because it catches the common cases but costs relatively little in terms of implementation.

Once Upon a Polymorphic Type (POPL’99) 20 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Type rules for UsageSP – 4: Data structures

• k

• ij
• `

• ij
• ij

• k

for all

• `

• k

• k

• k

• ij
• `

• k

• `

• i
• i

• k

• )

for all

• `

• f

• Once Upon a Polymorphic Type (POPL’99)

21 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Inference algorithm

• 1. Annotate program:

• x

• 2. Collect constraints:

• u

• u

• 3. Find optimal solution:

the ‘optimal’ annotation.

Once Upon a Polymorphic Type (POPL’99) 22 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Soundness Claim: Thunks marked

Proof strategy:

• 1. Provide an operational semantics expressing sharing and

thunks.

• 2. Ensure evaluation becomes ‘stuck’ if we use a thunk more than
• nce.
• 3. Show well-typed programs never become stuck.

Once Upon a Polymorphic Type (POPL’99) 23 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Typed operational semantics We base our operational semantics on Launchbury’s natural semantics for lazy evaluation. This semantics is untyped, since types are deleted at runtime (our language does not have a

construct). However, for the purposes of the proof it is convenient to annotate this semantics with types. Dealing with polymorphism is not straightforward. Since we allow evaluation under a type lambda, it is possible for a

create a thunk with a free type variable; if this thunk is na¨ ıvely placed in the heap the type variable becomes unbound. The solution is given in the paper.

Once Upon a Polymorphic Type (POPL’99) 24 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Related work

– Goldberg; Marlow, Gill (GHC)

– Linear types (Girard et. al.), affine types (Jacobs et. al.) – Clean (Barendsen et. al.): uniqueness analysis (dual to usage?); subsumption, data types, ML-polymorphism – Turner, Mossin, and Wadler: Once Upon A Type – extended by Mogensen: subsumption, data types – extended by Gustavsson: update markers

Once Upon a Polymorphic Type (POPL’99) 25 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Conclusion

– a type-based analysis – for a realistic language – that is efficiently computable – and has been proven sound.

Once Upon a Polymorphic Type (POPL’99) 26 20 January, 1999

UNIVERSITY OF

CAMBRIDGE

Future work

Haskell Compiler.

same framework.

‘work-safety’ results for them.

Once Upon a Polymorphic Type (POPL’99) 27 20 January, 1999