Your SlideShare is downloading. ×
Practical, Pluggable Types
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Practical, Pluggable Types

473
views

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 …

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
473
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

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