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

Practical, Pluggable Types

on

  • 901 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
901
Views on SlideShare
895
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 Practical, Pluggable Types Presentation Transcript

  • TypePlug -- Practical, Pluggable Types Nik Haldiman Marcus Denker Oscar Nierstrasz University of Bern © Marcus Denker
  • Types?
  • Static typing is Good! > Programs with failures are rejected — Reduces errors detected at runtime > Documentation > Minor inconvenience, major payoff © Marcus Denker
  • 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
  • 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 exotic type-systems > “Type-Systems as Tools” Gilad Bracha, OOPSLA 04: Pluggable Type-Systems © Marcus Denker
  • The Problem > Large, untyped code-base > Overhead for using pluggable types is high — Existing code needs to be annotated with type information © Marcus Denker
  • 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
  • Non-Nil Type-System > Declare variables to never be nil Object subclass: #Line typedInstanceVariables: ’startPoint endPoint <:nonNil:>’ typedClassVariables: ’’ poolDictionaries: '' DEMO category: 'Demo' © Marcus Denker
  • Non-Nil Type-System moveHorizontally: anInteger startPoint := self movePoint: startPoint horizontally: anInteger. endPoint:=self movePoint: endPoint horizontally: anInteger © Marcus Denker
  • 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
  • Non-Nil Type-System movePoint: aPoint horizontally: anInteger ↑ (aPoint addX: anInteger y: 0) <:nonNil :> © Marcus Denker
  • 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
  • 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
  • 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
  • Browser © Marcus Denker
  • 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
  • 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
  • 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