Your SlideShare is downloading. ×
0
TypePlug -- Practical, Pluggable Types

      Nik Haldiman
      Marcus Denker
      Oscar Nierstrasz



                 ...
Types?
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?
Pluggable Types




>    Optional: does not change the semantics

>    Pluggable: many different ones
     — Especially ex...
The Problem




>    Large, untyped code-base

>    Overhead for using pluggable types is high

     — Existing code needs...
TypePlug



>    Pluggable types for Squeak

>    Based on sub-method reflection framework
     (Demo on Wednesday!)

>    ...
Non-Nil Type-System



>    Declare variables to never be nil


Object subclass: #Line
   typedInstanceVariables: ’startPo...
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 (again)




>    Large, untyped code-base

>    Overhead for using pluggable types is high

     — Existing co...
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 (Roeltyper)...
Conclusion




>    TypePlug: Pragmatic framework for Pluggable Types

     —    Only type-check annotated code
     —    ...
Conclusion




>    TypePlug: Pragmatic framework for Pluggable Types

     —    Only type-check annotated code
     —    ...
Practical, Pluggable Types
Upcoming SlideShare
Loading in...5
×

Practical, Pluggable Types

515

Published on

Most languages fall into one of two camps: either they adopt a unique, static type system, or they abandon static type-checks for run-time checks. Pluggable types blur this division by (i) making static type systems optional, and (ii) supporting a choice of type systems for reasoning about different kinds of static properties. Dynamic languages can then benefit from static-checking without sacrificing dynamic features or committing to a unique, static type system. But the overhead of adopting pluggable types can be very high, especially if all existing code must be decorated with type annotations before any type-checking can be performed. We propose a practical and pragmatic approach to introduce pluggable type systems to dynamic languages. First of all, only annotated code is type-checked. Second, limited type inference is performed on unannotated code to reduce the number of reported errors. Finally, external annotations can be used to type third-party code. We present Typeplug, a Smalltalk implementation of our framework, and report on experience applying the framework to three different pluggable type systems.

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

  • Be the first to like this

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

No notes for slide

Transcript of "Practical, Pluggable Types"

  1. 1. TypePlug -- Practical, Pluggable Types Nik Haldiman Marcus Denker Oscar Nierstrasz University of Bern © Marcus Denker
  2. 2. Types?
  3. 3. Static typing is Good! > Programs with failures are rejected — Reduces errors detected at runtime > Documentation > Minor inconvenience, major payoff © Marcus Denker
  4. 4. 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 — False sense of security © Marcus Denker
  5. 5. Is it possible to have one’s cake and eat it, too?
  6. 6. Pluggable Types > Optional: does 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
  7. 7. The Problem > Large, untyped code-base > Overhead for using pluggable types is high — Existing code needs to be annotated with type information © Marcus Denker
  8. 8. TypePlug > Pluggable types for Squeak > Based on sub-method reflection framework (Demo on Wednesday!) > Case-Studies: — Non-Nil Types — Class Based Types — Confined Types © Marcus Denker
  9. 9. Non-Nil Type-System > Declare variables to never be nil Object subclass: #Line typedInstanceVariables: ’startPoint endPoint <:nonNil:>’ typedClassVariables: ’’ poolDictionaries: '' DEMO category: 'Demo' © Marcus Denker
  10. 10. Non-Nil Type-System moveHorizontally: anInteger startPoint := self movePoint: startPoint horizontally: anInteger. endPoint:=self movePoint: endPoint horizontally: anInteger © Marcus Denker
  11. 11. 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
  12. 12. Non-Nil Type-System movePoint: aPoint horizontally: anInteger ↑ (aPoint addX: anInteger y: 0) <:nonNil :> © Marcus Denker
  13. 13. The Problem (again) > Large, untyped code-base > Overhead for using pluggable types is high — Existing code needs to be annotated with type information © Marcus Denker
  14. 14. 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
  15. 15. 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
  16. 16. Browser © Marcus Denker
  17. 17. Future Work > Improve Type-Inference — Better algorithms — Explore heuristical type inference (Roeltyper) > Type Checking and Reflection — Use pluggable types to check reflective change © Marcus Denker
  18. 18. Conclusion > TypePlug: Pragmatic framework for Pluggable Types — Only type-check annotated code — Use type-inference — Explicit type-casts — External annotations for foreign code © Marcus Denker
  19. 19. Conclusion > TypePlug: Pragmatic framework for Pluggable Types — Only type-check annotated code — Use type-inference — Explicit type-casts — External annotations for foreign code 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.

×