once upon a polymorphic type
play

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

UNIVERSITY OF Once Upon a Polymorphic Type CAMBRIDGE 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


  1. UNIVERSITY OF Once Upon a Polymorphic Type CAMBRIDGE 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

  2. Why usage analysis? UNIVERSITY OF CAMBRIDGE Problem: � Lazy evaluation (call-by-need) is useful but slow Solutions: � Strictness analysis: convert call-by-need to call-by- value � Usage analysis: convert call-by-need to call-by- name Once Upon a Polymorphic Type (POPL’99) 2 20 January, 1999

  3. Lazy evaluation UNIVERSITY OF CAMBRIDGE let x = 3 + 4 y = 5 + 6 in x + x + y Heap, before and after: unnecessary update x : 3 + 4 x : 7 y : 5 + 6 y : 11 ✘ Unnecessary updates mean excess memory traffic. Once Upon a Polymorphic Type (POPL’99) 3 20 January, 1999

  4. The goal UNIVERSITY OF CAMBRIDGE Identify variables and subexpressions that will be evaluated at most once. Once Upon a Polymorphic Type (POPL’99) 4 20 January, 1999

  5. Usage analysis enables other optimisations too UNIVERSITY OF CAMBRIDGE Inlining: let x = e � y : case e of in � y : case x of : : : ! : : : : : : ! : : : Here x occurs in none of the case alternatives. We avoid constructing a thunk for x entirely, by inlining e . Always valid, but serious slow-down if lambda applied more than once; ‘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

  6. Plan of attack UNIVERSITY OF CAMBRIDGE Hask ell source Desugar Usage Usage inference inference Core Core-to-Core transforms Co de generation C / Assem bler 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

  7. How do we do it? UNIVERSITY OF CAMBRIDGE It seems that we should simply be able to count syntactic occurrences. But this is not enough. let y = 1 + 2 in let f = � x : x + y in f 3 + f 4 Here y appears once in its scope. But it is used twice , once for each call to f . The usage of y depends on the usage of f . Once Upon a Polymorphic Type (POPL’99) 7 20 January, 1999

  8. Types UNIVERSITY OF CAMBRIDGE We represent usage information in the types of expressions: ! 42 : Int 1 1 1 ! � x : Int : x : ( Int ! Int ) 1 1 1 1 ! 1 ! � x : Int : � y : Int : x + y : ( Int ! ( Int ! Int ) ) ! let x : Int = 3 + 4 1 y : Int = 5 + 6 ! in x + x + y : Int Once Upon a Polymorphic Type (POPL’99) 8 20 January, 1999

  9. Type syntax UNIVERSITY OF CAMBRIDGE Types � ::= T � k (unannotated) j � ! � 1 2 j 8 � : � j � Types u � ::= � (annotated) Usages u ::= 1 j ! � � for example, ! . 1 ! ( List Int ) ! Int Once Upon a Polymorphic Type (POPL’99) 9 20 January, 1999

  10. Type rules UNIVERSITY OF CAMBRIDGE Type judgements are of the form � ` e : � context expression type For example, the rule for addition: u u 1 2 � ` e : Int � ` e : Int 1 2 ( ` -PrimOp ) u 3 � ` e + e : Int 1 2 Once Upon a Polymorphic Type (POPL’99) 10 20 January, 1999

  11. Type rules for UsageSP – 1: Functions UNIVERSITY OF CAMBRIDGE � ; x : � ` e : � 1 2 (multiple occurrence) o c cur ( x; e ) > 1 ) j � j = ! 1 for all (free variables) o c cur ( y ; e ) > 0 ) j �( y ) j � u y 2 � ( ` -Abs ) u � ` � x : � : e : ( � ! � ) 1 1 2 � ) is defined syntactically . o c cur ( � ; ! let y : Int = 1 + 2 1 1 ! 1 in let f : ( Int ! Int ) = � x : Int : x + y ! in f 3 + f 4 : Int Here 1 , 1 , 2 . o c cur ( x; x + y ) = o c cur ( y ; x + y ) = o c cur ( f ; f 3 + f 4) = Once Upon a Polymorphic Type (POPL’99) 11 20 January, 1999

  12. Three design decisions UNIVERSITY OF CAMBRIDGE � Type polymorphism: – Should type variables be annotated or unannotated? What is the usage of a type abstraction? � Algebraic data structures: – How should constructor applications be typed? � The poisoning problem: – How can we avoid equating usages of all arguments to a common function? Once Upon a Polymorphic Type (POPL’99) 12 20 January, 1999

  13. Design decision 1: Type polymorphism UNIVERSITY OF CAMBRIDGE � Range of type variables: – Should type arguments be annotated or unannotated? 1 1 ! f : ( 8 � : � ! ( � ! ( � ; � ; � ) ) ) or ? 1 ! 1 1 ! f : ( 8 � : � ! ( � ! ( � ; � ; � ) ) ) � Type of type abstractions: – Given u , what is � ` e : � ` � � : e : ? Once Upon a Polymorphic Type (POPL’99) 13 20 January, 1999

  14. Type rules for UsageSP – 3: Type polymorphism UNIVERSITY OF Type abstractions and applications are treated as CAMBRIDGE ‘transparent’ for the purposes of usage annotation, since operationally they have no significance. These rules simply lift and lower the usage annotation. u � ; � ` e : � ( ` -TyAbs ) u � ` � � : e : ( 8 � : � ) u � ` e : ( 8 � : � ) 2 ( ` -TyApp ) u � ` e � : ( � [ � := � ]) 1 2 1 Once Upon a Polymorphic Type (POPL’99) 14 20 January, 1999

  15. Design decision 2: Data structures UNIVERSITY OF CAMBRIDGE Our language features user-defined algebraic data types such as data T r e e � = Br anch ( T r e e � ) � ( T r e e � ) j L e af � How should these be typed? Once Upon a Polymorphic Type (POPL’99) 15 20 January, 1999

  16. Data structures: First attempt UNIVERSITY OF CAMBRIDGE If we treat data constructors as normal functions, what usages should we place on the arguments and result? ? ? ? ? ? ? Br anch : 8 � : ( T r e e � ) ! ( � ! (( T r e e � ) ! ( T r e e � ) ) ) ✘ To make anch universally applicable, we must set ! . Br ? = : : : inaccurate. The usages ? really depend on how the constructed data is used , not on the constructor itself. Once Upon a Polymorphic Type (POPL’99) 16 20 January, 1999

  17. The tantalising opportunity UNIVERSITY OF CAMBRIDGE ! ! 1 ! ! let f : ( Int ! ( Int ! ( Int ; Int ) ) ) ! ! f = � x : Int : � y : Int : let p = : : : q = : : : in ( p; q ) in case f x y of ( p; q ) ! p + q Each component of the pair returned by f is used only once. Hence p and q need not be updated on evaluation. How can we propagate this information from the usage site (the case expression) to the construction site in f ? Once Upon a Polymorphic Type (POPL’99) 17 20 January, 1999

  18. Data structure usage propagation – 1 UNIVERSITY OF We propagate usage information through the type of the CAMBRIDGE constructed data. There are a number of alternatives here. data Pair � � = ( ; ) � � data T r e e � = Br anch ( T r e e � ) � ( T r e e � ) j L e af � 1. Give usage annotations for each constructor argument explicitly in the type: (typical application) ( ; ) 1 1 Int Int 3 4 Br anch ! 1 ! 1 Int t 3 t 1 2 1 1 u ! 1 ! u (( ; ) Int Int ) ( Br anch ( T r e e ! 1 ! 1 Int ) Int ( T r e e ! 1 ! 1 Int ) ) (effective type) 1 u j ( L e af Int ) This is the most general approach, but it is expensive. Once Upon a Polymorphic Type (POPL’99) 18 20 January, 1999

  19. Data structure usage propagation – 2 UNIVERSITY OF CAMBRIDGE 2. Attach usage annotations to each type argument [BS96]: 1 1 1 ( ; ) Int Int 3 4 Br anch Int t 3 t 1 2 1 1 u 1 ? 1 1 ? u (( ; ) Int Int ) ( Br anch ( T r e e Int ) Int ( T r e e Int ) ) 1 u j ( L e af Int ) 3. Assume all constructor arguments will be used more than once. ( ; ) Int Int 3 4 Br anch Int t 3 t 1 2 ! ! u ! ! ! u (( ; ) Int Int ) ( Br anch ( T r e e Int ) Int ( T r e e Int ) ) ! u j ( L e af Int ) Once Upon a Polymorphic Type (POPL’99) 19 20 January, 1999

  20. Data structure usage propagation – 3 UNIVERSITY OF CAMBRIDGE 4. Identify usage annotations for each constructor argument with the overall usage of the constructed data. ( ; ) Int Int 3 4 Br anch Int t 3 t 1 2 u u u u u u u (( ; ) Int Int ) ( Br anch ( T r e e Int ) Int ( T r e e Int ) ) u u j ( L e af Int ) 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

  21. Type rules for UsageSP – 4: Data structures UNIVERSITY OF CAMBRIDGE data T � = C � k i ij for all 0 0 u � ` e : � � 4 ( � [ � := � ]) j j ij k k ij ij ( ` -Con ) u � ` C � e : ( T � ) i k j k data T � = C � k i ij u � ` e : ( T � ) k for all 0 0 1 u � ` e : � � 4 (( � [ � := � ]) ! � ) i i ij k k i i ( ` -Case ) � ` case e of C ! e : � i i Once Upon a Polymorphic Type (POPL’99) 21 20 January, 1999

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend