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.

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

6. Is it possible to have one’s cake and eat it, too?

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

8. The Problem
> Large, untyped code-base
> Overhead for using pluggable types is high
— Existing code needs to be annotated with type information
© Marcus Denker

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

10. Non-Nil Type-System
> Declare variables to never be nil
Object subclass: #Line
typedInstanceVariables: ’startPoint endPoint <:nonNil:>’
typedClassVariables: ’’
poolDictionaries: ''
DEMO
category: 'Demo'
© Marcus Denker

11. Non-Nil Type-System
moveHorizontally: anInteger
startPoint := self movePoint: startPoint
horizontally: anInteger.
endPoint:=self movePoint: endPoint
horizontally: anInteger
© Marcus Denker

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

13. Non-Nil Type-System
movePoint: aPoint horizontally: anInteger
↑ (aPoint addX: anInteger y: 0) <:nonNil :>
© Marcus Denker

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

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

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

17. Browser
© Marcus Denker

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

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

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