TypePlug -- Practical, Pluggable Types

      Marcus Denker
      with:
      Nik Haldiman
      Oscar Nierstrasz

       ...
Types?



© Marcus Denker
Caveat....



© Marcus Denker
I am not a Type Person



© Marcus Denker
© Marcus Denker
Static types are Evil



© Marcus Denker
© Marcus Denker
© Marcus Denker
© Marcus Denker
© Marcus Denker
Static types are Evil?



© Marcus Denker
Static is Evil!



© Marcus Denker
The Future....



© Marcus Denker
...change



© Marcus Denker
...evolution



© Marcus Denker
...dynamic



© Marcus Denker
...biological



© Marcus Denker
Static typing is Good!




>    Programs with failures are rejected
     — Reduces errors detected at runtime

>    Docume...
Static typing is Evil!



>    Exactly all cool programs are rejected
     — Reflection?!


>    Inconvenience is not at al...
Is it possible to have one’s cake and eat it, too?
History: Strongtalk


>    Anymorphic. Startup (ca. 1996)
     — Self team, from Sun
     — Smalltalk VM

>    Smalltalk w...
Problem of Mandatory Types



>    Types constrain the expressiveness of a Language

>    Types make systems more brittle
...
Pluggable Types



>    Optional: do not change the semantics



>    Pluggable: many different ones
     — Especially exo...
Pluggable Types: Language


>    Optional types do not constrain the expressiveness
     — We can ignore the type system i...
Pluggable Types: Pluggability



>    There is a lot of very interesting research on Types

>    It is very hard to get it...
Pluggable Types: Types as Tools


                                  Type Checker




                             We are f...
Type Inference?


>    Isnʼt Type Inference enough?

>    Type Inference is cool. But itʼs a Type-system

>    No Type Ann...
Pluggable Types at SCG


>    Research about Software Evolution

     — Reflection to support dynamic change



>    We lik...
Methods and Reflection



>    Method are Objects
     — e.g in Smalltalk


>    No high-level model for sub-method element...
Sub-Method Reflection



>    Many tools work on sub method level
     — Profiler, Refactoring Tool, Debugger, Type Checker
...
Sub-Method Reflection



                               >   Sub-method Structure
   :ReflectiveMethod                (AST)
 ...
Sub-Method Reflection: Behavior




                                 meta-object


links
> Sub-method Reflection           a...
Sub-Method Reflection: Annotations



>    Source visible annotations
                  (9 raisedTo: 10000) <:evaluateAtCom...
TypePlug



>    Pluggable types for Squeak

>    Based on sub-method reflection framework

>    Case-Studies:
     — Non-N...
The Problem




>    Large, untyped code-base

>    Overhead for using pluggable types is high

     — Existing code needs...
Example: Non-Nil Type-System



>    Declare variables to never be nil


Object subclass: #Line
   typedInstanceVariables:...
Non-Nil Type-System




moveHorizontally: anInteger

  startPoint := self movePoint: startPoint
                    horizo...
Non-Nil Type-System




moveHorizontally: anInteger

  startPoint := self movePoint: startPoint
                    horizo...
Non-Nil Type-System




movePoint: aPoint horizontally: anInteger


            
        ↑ (aPoint addX: anInteger y: 0) <...
The Problem (repeat)




>    Large, untyped code-base

>    Overhead for using pluggable types is high

     — Existing c...
Solution



>    Only type-check annotated code

>    Use type-inference to infer types of non-annotated code

>    Explic...
External Type Annotations


>    We need to annotate existing code
     — Especially libraries and frameworks
     — Examp...
Browser




© Marcus Denker
Future Work




>    Improve Type-Inference
     — Better algorithms
     — Explore heuristical type inference

>    Type ...
Conclusion




>    Pluggable Types
     — All positive effects of static types
     — Avoid the problems


>    TypePlug:...
Conclusion




>    Pluggable Types
     — All positive effects of static types
     — Avoid the problems


>    TypePlug:...
Talk: Practical, Pluggable Types
Upcoming SlideShare
Loading in...5
×

Talk: Practical, Pluggable Types

817

Published on

PPS laboratory, Universite Paris Diderot - Paris 7 "Practical, Pluggable Types" 04.12.2008

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
817
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Talk: Practical, Pluggable Types

  1. 1. TypePlug -- Practical, Pluggable Types Marcus Denker with: Nik Haldiman Oscar Nierstrasz University of Bern © Marcus Denker
  2. 2. Types? © Marcus Denker
  3. 3. Caveat.... © Marcus Denker
  4. 4. I am not a Type Person © Marcus Denker
  5. 5. © Marcus Denker
  6. 6. Static types are Evil © Marcus Denker
  7. 7. © Marcus Denker
  8. 8. © Marcus Denker
  9. 9. © Marcus Denker
  10. 10. © Marcus Denker
  11. 11. Static types are Evil? © Marcus Denker
  12. 12. Static is Evil! © Marcus Denker
  13. 13. The Future.... © Marcus Denker
  14. 14. ...change © Marcus Denker
  15. 15. ...evolution © Marcus Denker
  16. 16. ...dynamic © Marcus Denker
  17. 17. ...biological © Marcus Denker
  18. 18. Static typing is Good! > Programs with failures are rejected — Reduces errors detected at runtime > Documentation > Minor inconvenience, major payoff © Marcus Denker
  19. 19. Static typing is Evil! > Exactly all cool programs are rejected — Reflection?! > Inconvenience is not at all “minor” — Typed programs hard to change + evolve > Only the most trivial errors are detected — We would have found those anyway before deployment © Marcus Denker
  20. 20. Is it possible to have one’s cake and eat it, too?
  21. 21. History: Strongtalk > Anymorphic. Startup (ca. 1996) — Self team, from Sun — Smalltalk VM > Smalltalk with a Type System > Observations: — Types not needed for performance — Optional Types are nice (Documentation!) – Can be introduced later when the system is stable © Marcus Denker
  22. 22. Problem of Mandatory Types > Types constrain the expressiveness of a Language > Types make systems more brittle — Security and Performance — If types fail, behavior is undefined > But Type-Systems are proven to be correct!? — Real world is too complex to formalize — Implementation will have bugs © Marcus Denker
  23. 23. Pluggable Types > Optional: do not change the semantics > Pluggable: many different ones — Especially exotic type-systems > “Type-Systems as Tools” Gilad Bracha, OOPSLA 04: Pluggable Type-Systems © Marcus Denker
  24. 24. Pluggable Types: Language > Optional types do not constrain the expressiveness — We can ignore the type system if we want — (or turn it off completely) > New language models can be realized faster > Inventing the Future is hard if it needs to be type-save — Example: NewSpeak © Marcus Denker
  25. 25. Pluggable Types: Pluggability > There is a lot of very interesting research on Types > It is very hard to get it into the hands of Programmers — Sun will not change Java for you! — (even though you suffered with java for years for your research) > Pluggable type-systems free type research from language adoption! © Marcus Denker
  26. 26. Pluggable Types: Types as Tools Type Checker We are free to explore the unthinkable in our Room (Research!) © Marcus Denker
  27. 27. Type Inference? > Isnʼt Type Inference enough? > Type Inference is cool. But itʼs a Type-system > No Type Annotation != No Type System Pluggable Types are very likely to use Inference © Marcus Denker
  28. 28. Pluggable Types at SCG > Research about Software Evolution — Reflection to support dynamic change > We like to use dynamically typed systems — Smalltalk / Squeak > Thinking is not constrained by Types — Very important! © Marcus Denker
  29. 29. Methods and Reflection > Method are Objects — e.g in Smalltalk > No high-level model for sub-method elements — Message sends — Assignments — Variable access > Structural reflection stops at the granularity of methods © Marcus Denker 30
  30. 30. Sub-Method Reflection > Many tools work on sub method level — Profiler, Refactoring Tool, Debugger, Type Checker > Communication between tools needed — example: Code coverage > All tools use different representations — Tools are harder to build — Communication not possible © Marcus Denker
  31. 31. Sub-Method Reflection > Sub-method Structure :ReflectiveMethod (AST) annotation > Annotations — Source visible annotation — non-visible > Causally connected © Marcus Denker
  32. 32. Sub-Method Reflection: Behavior meta-object links > Sub-method Reflection activation condition source code (AST) © Marcus Denker
  33. 33. Sub-Method Reflection: Annotations > Source visible annotations (9 raisedTo: 10000) <:evaluateAtCompiletime:> > Every node can be annotated > Semantics: Compiler Plugins > Type Annotations? © Marcus Denker
  34. 34. TypePlug > Pluggable types for Squeak > Based on sub-method reflection framework > Case-Studies: — Non-Nil Types — Class Based Types — Confined Types Master Thesis: Nik Haldiman © Marcus Denker
  35. 35. The Problem > Large, untyped code-base > Overhead for using pluggable types is high — Existing code needs to be annotated with type information © Marcus Denker
  36. 36. Example: Non-Nil Type-System > Declare variables to never be nil Object subclass: #Line typedInstanceVariables: ’startPoint endPoint <:nonNil:>’ typedClassVariables: ’’ poolDictionaries: '' category: 'Demo' © Marcus Denker
  37. 37. Non-Nil Type-System moveHorizontally: anInteger startPoint := self movePoint: startPoint horizontally: anInteger. endPoint:=self movePoint: endPoint horizontally: anInteger © Marcus Denker
  38. 38. Non-Nil Type-System moveHorizontally: anInteger startPoint := self movePoint: startPoint horizontally: anInteger. endPoint:=self movePoint: endPoint horizontally: anInteger <- type ’TopType’ of expression is not compatible with type ’nonNil’ of variable ’endPoint’. © Marcus Denker
  39. 39. Non-Nil Type-System movePoint: aPoint horizontally: anInteger ↑ (aPoint addX: anInteger y: 0) <:nonNil :> © Marcus Denker
  40. 40. The Problem (repeat) > Large, untyped code-base > Overhead for using pluggable types is high — Existing code needs to be annotated with type information © Marcus Denker
  41. 41. Solution > Only type-check annotated code > Use type-inference to infer types of non-annotated code > Explicit type-casts > Allow external annotations for foreign code © Marcus Denker
  42. 42. External Type Annotations > We need to annotate existing code — Especially libraries and frameworks — Example: Object>>#hash is <: nonNil :> > We do not want to change the program code! > Solution: External Type Annotations — Added and modified in the TypesBrowser — Do not change the source — External representation: Type Packages © Marcus Denker
  43. 43. Browser © Marcus Denker
  44. 44. Future Work > Improve Type-Inference — Better algorithms — Explore heuristical type inference > Type Checking and Reflection — Use pluggable types to check reflective change © Marcus Denker
  45. 45. Conclusion > Pluggable Types — All positive effects of static types — Avoid the problems > TypePlug: Pragmatic framework for Pluggable Types — Example in the context of Smalltalk/Squeak © Marcus Denker
  46. 46. Conclusion > Pluggable Types — All positive effects of static types — Avoid the problems > TypePlug: Pragmatic framework for Pluggable Types — Example in the context of Smalltalk/Squeak Questions? © Marcus Denker
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×