Practical, Pluggable Types
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Practical, Pluggable Types

on

  • 926 views

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 ...

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.

Statistics

Views

Total Views
926
Views on SlideShare
920
Embed Views
6

Actions

Likes
0
Downloads
2
Comments
0

1 Embed 6

http://www.slideshare.net 6

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Practical, Pluggable Types Presentation Transcript

  • 1. TypePlug -- Practical, Pluggable Types Nik Haldiman Marcus Denker Oscar Nierstrasz University of Bern © Marcus Denker
  • 2. Types?
  • 3. Static typing is Good! > Programs with failures are rejected — Reduces errors detected at runtime > Documentation > Minor inconvenience, major payoff © Marcus Denker
  • 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. Is it possible to have one’s cake and eat it, too?
  • 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. 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. 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. 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. Non-Nil Type-System moveHorizontally: anInteger startPoint := self movePoint: startPoint horizontally: anInteger. endPoint:=self movePoint: endPoint horizontally: anInteger © Marcus Denker
  • 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. Non-Nil Type-System movePoint: aPoint horizontally: anInteger ↑ (aPoint addX: anInteger y: 0) <:nonNil :> © Marcus Denker
  • 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. 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. 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. Browser © Marcus Denker
  • 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. 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. 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