Big Bang Designing a Statically Typed Scripting Language Pottayil - - PowerPoint PPT Presentation
Big Bang Designing a Statically Typed Scripting Language Pottayil Harisanker Menon, Zachary Palmer, Scott F. Smith, Alexander Rozenshteyn The Johns Hopkins University June 11, 2012 Scripting Languages Terse Flexible Easy to
Designing a Statically Typed Scripting Language
Pottayil Harisanker Menon, Zachary Palmer, Scott F. Smith, Alexander Rozenshteyn
The Johns Hopkins University
June 11, 2012
✦ Terse ✦ Flexible ✦ Easy to learn ✦ Amenable to rapid development ✪
✦ Terse ✦ Flexible ✦ Easy to learn ✦ Amenable to rapid development ✪ Dynamically typed
❼ Performance ❼ Debugging ❼ Programmer understanding
❼ e.g. DRuby, Typed Racket ❼
❼ ❼
❼
❼ ❼
❼ e.g. DRuby, Typed Racket ❼ Existing language features are hard to type
❼ ❼
❼
❼ ❼
❼ e.g. DRuby, Typed Racket ❼ Existing language features are hard to type
❼ DRuby does not typecheck the entire Ruby API ❼
❼
❼ ❼
❼ e.g. DRuby, Typed Racket ❼ Existing language features are hard to type
❼ DRuby does not typecheck the entire Ruby API ❼ Typechecking runtime metaprogramming is hard
❼
❼ ❼
❼ e.g. DRuby, Typed Racket ❼ Existing language features are hard to type
❼ DRuby does not typecheck the entire Ruby API ❼ Typechecking runtime metaprogramming is hard
❼ These systems require programmer annotation
❼ ❼
❼ e.g. DRuby, Typed Racket ❼ Existing language features are hard to type
❼ DRuby does not typecheck the entire Ruby API ❼ Typechecking runtime metaprogramming is hard
❼ These systems require programmer annotation
❼ Type annotations reduce terseness ❼
❼ e.g. DRuby, Typed Racket ❼ Existing language features are hard to type
❼ DRuby does not typecheck the entire Ruby API ❼ Typechecking runtime metaprogramming is hard
❼ These systems require programmer annotation
❼ Type annotations reduce terseness ❼ Annotations can be overly restrictive
❼ Design type system and execution model
concurrently
❼ ❼ ❼ ❼ ❼
❼ Design type system and execution model
concurrently
❼ Be minimalistic: most features are encoded ❼ ❼ ❼ ❼
❼ Design type system and execution model
concurrently
❼ Be minimalistic: most features are encoded ❼ Use static near-equivalents for dynamic
patterns
❼ ❼ ❼
❼ Design type system and execution model
concurrently
❼ Be minimalistic: most features are encoded ❼ Use static near-equivalents for dynamic
patterns
❼ Infer all types: no type declarations ❼ ❼
❼ Design type system and execution model
concurrently
❼ Be minimalistic: most features are encoded ❼ Use static near-equivalents for dynamic
patterns
❼ Infer all types: no type declarations ❼ Use a whole-program typechecking model ❼
❼ Design type system and execution model
concurrently
❼ Be minimalistic: most features are encoded ❼ Use static near-equivalents for dynamic
patterns
❼ Infer all types: no type declarations ❼ Use a whole-program typechecking model ❼ Use type information to improve runtime
memory layout
❼ BigBang encodes to a core language ❼
❼ ❼ ❼ ❼ ❼
❼ BigBang encodes to a core language ❼ TinyBang has very few features:
❼ ❼ ❼ ❼ ❼
❼ BigBang encodes to a core language ❼ TinyBang has very few features:
❼ Primitives ❼ ❼ ❼ ❼
❼ BigBang encodes to a core language ❼ TinyBang has very few features:
❼ Primitives ❼ Labels ❼ ❼ ❼
❼ BigBang encodes to a core language ❼ TinyBang has very few features:
❼ Primitives ❼ Labels ❼ Onions ❼ ❼
❼ BigBang encodes to a core language ❼ TinyBang has very few features:
❼ Primitives ❼ Labels ❼ Onions ❼ Scapes ❼
❼ BigBang encodes to a core language ❼ TinyBang has very few features:
❼ Primitives ❼ Labels ❼ Onions ❼ Scapes ❼ Exceptions
❼ BigBang encodes to a core language ❼ TinyBang has very few features:
❼ Primitives ❼ Labels ❼ Onions ❼ Scapes ❼ Exceptions
(and that’s all)
❼ Labels simply wrap data ❼ ❼ ❼ ❼
❼ ❼
❼ Labels simply wrap data (polymorphic variants) ❼ ❼ ❼ ❼
❼ ❼
("Tom" ≇
❼ Labels simply wrap data (polymorphic variants) ❼ Onions combine data ❼ ❼ ❼
❼ ❼
❼ Labels simply wrap data (polymorphic variants) ❼ Onions combine data ❼ Data may be unlabeled (vs. extensible records) ❼ ❼
❼ ❼
❼ Labels simply wrap data (polymorphic variants) ❼ Onions combine data ❼ Data may be unlabeled (vs. extensible records) ❼ Onion data is projected by type ❼
❼ ❼
= ⇒
❼ Labels simply wrap data (polymorphic variants) ❼ Onions combine data ❼ Data may be unlabeled (vs. extensible records) ❼ Onion data is projected by type ❼ Onioning is asymmetric (right-precedence)
❼ ❼
= ⇒
❼ Labels simply wrap data (polymorphic variants) ❼ Onions combine data ❼ Data may be unlabeled (vs. extensible records) ❼ Onion data is projected by type ❼ Onioning is asymmetric (right-precedence)
❼ Used to encode overriding ❼
= ⇒
❼ Labels simply wrap data (polymorphic variants) ❼ Onions combine data ❼ Data may be unlabeled (vs. extensible records) ❼ Onion data is projected by type ❼ Onioning is asymmetric (right-precedence)
❼ Used to encode overriding ❼ Important for type checking (later)
= ⇒
❼ Scapes are functions ❼ ❼ ❼ x -> x
❼ Scapes are functions with input patterns ❼ ❼ ❼ ❵❆ x & ❵❇ y -> x + y
❼ Scapes are functions with input patterns ❼ ❼ ❼ (❵❆ x & ❵❇ y -> x + y) (❵❆ 1 & ❵❇ 2)
= ⇒
3
❼ Scapes are functions with input patterns ❼ Onions of scapes apply the first matching scape ❼ ❼ ❞❡❢ list = ❵❍❞ 4 & ❵❚❧ ❵◆✐❧ ✭✮ ✐♥ ((❵❍❞ h -> h) & (❵◆✐❧ _ -> ✭✮)) list
= ⇒
4
❼ Scapes are functions with input patterns ❼ Onions of scapes apply the first matching scape ❼ Encodes typecasing ❼ ❞❡❢ list = ❵❍❞ 4 & ❵❚❧ ❵◆✐❧ ✭✮ ✐♥ ((❵❍❞ h -> h) & (❵◆✐❧ _ -> ✭✮)) list
∼ =
❞❡❢ list = ❵❍❞ 4 & ❵❚❧ ❵◆✐❧ ✭✮ ✐♥ ❝❛s❡ list ♦❢ ❵◆✐❧ _ -> ✭✮ ❵❍❞ h -> h
❼ Scapes are functions with input patterns ❼ Onions of scapes apply the first matching scape ❼ Encodes typecasing ❼ Refines First-Class Cases [Chae et al. ’06] ❞❡❢ list = ❵❍❞ 4 & ❵❚❧ ❵◆✐❧ ✭✮ ✐♥ ((❵❍❞ h -> h) & (❵◆✐❧ _ -> ✭✮)) list
∼ =
❞❡❢ list = ❵❍❞ 4 & ❵❚❧ ❵◆✐❧ ✭✮ ✐♥ ❝❛s❡ list ♦❢ ❵◆✐❧ _ -> ✭✮ ❵❍❞ h -> h
❼ Label contents are mutable ❼
❞❡❢ y = ❵❆ 2 ✐♥ (❵❆ x -> x = 5 ✐♥ y) y = ⇒ ❵❆ 5
❼ Label contents are mutable ❼ But onioning is functional extension
❞❡❢ x = ❵❆ 0 & ❵❇ 1 ✐♥ ❞❡❢ y = ❵❇ 2 & ❵❈ 3 ✐♥ ❞❡❢ z = x & y ✐♥ x = ⇒ ❵❆ 0 & ❵❇ 1
❼ Label contents are mutable ❼ But onioning is functional extension
❞❡❢ x = ❵❆ 0 & ❵❇ 1 ✐♥ ❞❡❢ y = ❵❇ 2 & ❵❈ 3 ✐♥ ❞❡❢ z = x & y ✐♥ z = ⇒ ❵❆ 0 & ❵❇ 2 & ❵❈ 3
Function self-awareness can be encoded by:
❼ Adding a ❵s❡❧❢ match to each pattern ❼
⇓
Function self-awareness can be encoded by:
❼ Adding a ❵s❡❧❢ match to each pattern ❼
⇓
Function self-awareness can be encoded by:
❼ Adding a ❵s❡❧❢ match to each pattern ❼ Adding a ❵s❡❧❢ value to each invocation
⇓
❞❡❢ factorial = x: ✐♥t
✐❢ x == 0 t❤❡♥ 1 ❡❧s❡ s❡❧❢ (x-1) * x ✐♥ s❡❧❢ 5
⇓
❞❡❢ factorial = x: ✐♥t & ❵s❡❧❢ s❡❧❢
✐❢ x == 0 t❤❡♥ 1 ❡❧s❡ s❡❧❢ (x-1) * x ✐♥ factorial (5 & ❵s❡❧❢ factorial)
❼ Objects are encoded as onions ❼ ❼ ❝❧❛ss Point { ✐♥t x = 2; ✐♥t y = 3; ✐♥t l1() { r❡t✉r♥ x+y; } }
❼ Objects are encoded as onions ❼ Each field is a labeled value ❼ ❝❧❛ss Point { ✐♥t x = 2; ✐♥t y = 3; ✐♥t l1() { r❡t✉r♥ x+y; } } ❵① 2 & ❵② 3
❼ Objects are encoded as onions ❼ Each field is a labeled value ❼ Message handler scapes encode methods ❝❧❛ss Point { ✐♥t x = 2; ✐♥t y = 3; ✐♥t l1() { r❡t✉r♥ x+y; } } ❵① 2 & ❵② 3 & ( ❵❧✶ ✭✮ -> s❡❧❢.①+s❡❧❢.②)
❼ Objects are encoded as onions ❼ Each field is a labeled value ❼ Message handler scapes encode methods ❝❧❛ss Point { ✐♥t x = 2; ✐♥t y = 3; ✐♥t l1() { r❡t✉r♥ x+y; } } ❵① 2 & ❵② 3 & ( ❵❧✶ ✭✮ & ❵s❡❧❢ s❡❧❢ -> s❡❧❢.①+s❡❧❢.②)
❞❡❢ o = ❵① 2 & ❵② 3 & ( ❵❧✶ ✭✮ & ❵s❡❧❢ s❡❧❢ -> s❡❧❢.① + s❡❧❢.② ) ✐♥ (❵① x -> x) o
∼ = o.①
❞❡❢ o = ❵① 2 & ❵② 3 & ( ❵❧✶ ✭✮ & ❵s❡❧❢ s❡❧❢ -> s❡❧❢.① + s❡❧❢.② ) ✐♥
❵s❡❧❢ o )
∼ = o.❧✶✭✮
❼ Inheritance occurs by onion extension ❼ ❞❡❢ mypoint = ❵① 2 & ❵② 3 & (❵❧✶ ✭✮ -> s❡❧❢.① + s❡❧❢.②) ✐♥ ❞❡❢ mixinFar = (❵✐s❋❛r ✭✮
✐♥ ❞❡❢ myFpoint = mypoint & mixinFar ✐♥ myFpoint .✐s❋❛r ✭✮
❼ Inheritance occurs by onion extension ❼ Mixins are the extension onion ❞❡❢ mypoint = ❵① 2 & ❵② 3 & (❵❧✶ ✭✮ -> s❡❧❢.① + s❡❧❢.②) ✐♥ ❞❡❢ mixinFar = (❵✐s❋❛r ✭✮
✐♥ ❞❡❢ myFpoint = mypoint & mixinFar ✐♥ myFpoint .✐s❋❛r ✭✮
❼ Classes are object factories ❼ ❞❡❢ Point = ❵♥❡✇ (❵① x & ❵② y) -> ❵① x & ❵② y & (❵❧✶ ✭✮ -> s❡❧❢.① + s❡❧❢.②) ✐♥ . . .
❼ Classes are object factories ❼ Subclass factories instantiate and extend ❞❡❢ Point = ❵♥❡✇ (❵① x & ❵② y) -> ❵① x & ❵② y & (❵❧✶ ✭✮ -> s❡❧❢.① + s❡❧❢.②) ✐♥ ❞❡❢ Point3D = ❵♥❡✇ (a: ❵① _ & ❵② _ & ❵③ z) -> ❞❡❢ super = (Point .♥❡✇ a) ✐♥ super & ❵③ 0 & (❵❧✶ ✭✮ -> super .❧✶✭✮) + s❡❧❢.③) ✐♥ Point3D (❵♥❡✇ (❵① 1 & ❵② 2 & ❵③ 3))
❼ Overloading is trivial with scapes ❼ ❼ ❞❡❢ join = ((❵① x:✐♥t & ❵② y:✐♥t) -> x + y) & ((❵① _:✉♥✐t & ❵② _:✉♥✐t) -> ✭✮) ✐♥ join (❵① 1 & ❵② 2) & join (❵① ✭✮ & ❵② ✭✮)
❼ Overloading is trivial with scapes ❼ Onion extension allows incremental overloading ❼ ❞❡❢ join = ((❵① x:✐♥t & ❵② y:✐♥t) -> x + y) & ((❵① _:✉♥✐t & ❵② _:✉♥✐t) -> ✭✮) ✐♥ ❞❡❢ x = join (❵① 1 & ❵② 2) & join (❵① ✭✮ & ❵② ✭✮) ✐♥ ❞❡❢ join = join & ((❵① x:✐♥t & ❵② _:✉♥✐t) -> x + 1) ✐♥ join (❵① 5 & ❵② ✭✮)
❼ Overloading is trivial with scapes ❼ Onion extension allows incremental overloading ❼ Default arguments are easy too ❞❡❢ inc = a: ❵① x -> ❞❡❢ by = ((_ -> 1) & (❵② y -> y)) a ✐♥ x + by ✐♥ inc (❵① 1 & ❵② 2) + inc (❵① 6)
❼ BigBang uses TinyBang as a core language ❼ ❼ s❡❧❢ ❼ ❼
❼ BigBang uses TinyBang as a core language ❼ BigBang will provide macros for
syntax/features
❼ s❡❧❢ ❼ ❼
❼ BigBang uses TinyBang as a core language ❼ BigBang will provide macros for
syntax/features
❼ s❡❧❢, class syntax, etc. defined in this way ❼ ❼
❼ BigBang uses TinyBang as a core language ❼ BigBang will provide macros for
syntax/features
❼ s❡❧❢, class syntax, etc. defined in this way ❼ User extensions can be specified ❼
❼ BigBang uses TinyBang as a core language ❼ BigBang will provide macros for
syntax/features
❼ s❡❧❢, class syntax, etc. defined in this way ❼ User extensions can be specified ❼ Similar to Racket (Languages as Libraries
[Tobin-Hochstadt et al., 2011])
A scripting language’s type system must be:
✽ Expressive
❼ ❼
✺
❼ ❼ ❼
❩
❼
✷
❼
A scripting language’s type system must be:
✽ Expressive
❼ Duck typing, conditional types ❼
✺
❼ ❼ ❼
❩
❼
✷
❼
A scripting language’s type system must be:
✽ Expressive
❼ Duck typing, conditional types ❼ No arbitrary cutoffs
✺
❼ ❼ ❼
❩
❼
✷
❼
A scripting language’s type system must be:
✽ Expressive
❼ Duck typing, conditional types ❼ No arbitrary cutoffs
✺ Comprehensible
❼ ❼ ❼
❩
❼
✷
❼
A scripting language’s type system must be:
✽ Expressive
❼ Duck typing, conditional types ❼ No arbitrary cutoffs
✺ Comprehensible
❼ Types should be legible ❼ ❼
❩
❼
✷
❼
A scripting language’s type system must be:
✽ Expressive
❼ Duck typing, conditional types ❼ No arbitrary cutoffs
✺ Comprehensible
❼ Types should be legible ❼ Sources of type errors must be clear ❼
❩
❼
✷
❼
A scripting language’s type system must be:
✽ Expressive
❼ Duck typing, conditional types ❼ No arbitrary cutoffs
✺ Comprehensible
❼ Types should be legible ❼ Sources of type errors must be clear ❼ Intuitive non-local inference
❩
❼
✷
❼
A scripting language’s type system must be:
✽ Expressive
❼ Duck typing, conditional types ❼ No arbitrary cutoffs
✺ Comprehensible
❼ Types should be legible ❼ Sources of type errors must be clear ❼ Intuitive non-local inference
❩ Efficient
❼
✷
❼
A scripting language’s type system must be:
✽ Expressive
❼ Duck typing, conditional types ❼ No arbitrary cutoffs
✺ Comprehensible
❼ Types should be legible ❼ Sources of type errors must be clear ❼ Intuitive non-local inference
❩ Efficient
❼ Short compile times for dev. iterations
✷
❼
A scripting language’s type system must be:
✽ Expressive
❼ Duck typing, conditional types ❼ No arbitrary cutoffs
✺ Comprehensible
❼ Types should be legible ❼ Sources of type errors must be clear ❼ Intuitive non-local inference
❩ Efficient
❼ Short compile times for dev. iterations
✷ Easy to Use
❼
A scripting language’s type system must be:
✽ Expressive
❼ Duck typing, conditional types ❼ No arbitrary cutoffs
✺ Comprehensible
❼ Types should be legible ❼ Sources of type errors must be clear ❼ Intuitive non-local inference
❩ Efficient
❼ Short compile times for dev. iterations
✷ Easy to Use
❼ Usable to teach introductory courses
For BigBang, we choose:
✽ ✷
Subtype inference
✽
Call-Site Polymorphism
✽ ✺
Path sensitivity
✺ ✷
Flow insensitivity
✽ ❩
Asymmetric concatenation
❩
Incremental typechecking
✽ Expressive ✺ Comprehensible ❩ Efficient ✷ Easy to Use
❼ No programmer type declarations ❼ ❼ ❵① ❵② ✭✮
❼ No programmer type declarations ❼ Supports duck-typing ❼ ❵① ❵② ✭✮
❼ No programmer type declarations ❼ Supports duck-typing ❼ Supports nominal typing (labels as names) ❵① ❵② ✭✮
❼ No programmer type declarations ❼ Supports duck-typing ❼ Supports nominal typing (labels as names) (e.g. ❵① 1 & ❵② 2 & ‘Point ✭✮ )
❼ All functions polymorphic; no ❧❡t restriction ❼ ❼ ❼
❼ All functions polymorphic; no ❧❡t restriction ❼ New contour for each non-recursive call site ❼ ❼
❼ All functions polymorphic; no ❧❡t restriction ❼ New contour for each non-recursive call site ❼ Only one contour for each recursive cycle ❼
❼ All functions polymorphic; no ❧❡t restriction ❼ New contour for each non-recursive call site ❼ Only one contour for each recursive cycle ❼ A variant of both nCFA and CPA
❞❡❢ f = x -> ❵❆ x ✐♥ ❞❡❢ x = f 0 ✐♥ ❞❡❢ y = f ✭✮ ✐♥ ❞❡❢ z = f (❵❇ 2 & ❵❈ 3) ✐♥ . . . ❵❆ ❵❆ ✭✮ ❵❆ ❵❇ ❵❈
❞❡❢ f = x -> ❵❆ x ✐♥ ❞❡❢ x = f 0 ✐♥ ❞❡❢ y = f ✭✮ ✐♥ ❞❡❢ z = f (❵❇ 2 & ❵❈ 3) ✐♥ . . . x =
⇒ ❵❆ 0
y =
⇒ ❵❆ ✭✮
z =
⇒ ❵❆ (❵❇ 2 & ❵❈ 3)
❼ Scape application based on pattern match ❼ ❼ ❼
❼ Scape application based on pattern match ❼ Constraints expanded only if input matches ❼ ❼
❼ Scape application based on pattern match ❼ Constraints expanded only if input matches ❼ With polymorphism, gives path sensitivity ❼
❼ Scape application based on pattern match ❼ Constraints expanded only if input matches ❼ With polymorphism, gives path sensitivity ❼ Refines Conditional Types [Aiken et al. ’94]
❞❡❢ f = (❵❆ x -> x) & (❵❇ y -> ✭✮) ✐♥ f ❵❆ 3
❞❡❢ f = (❵❆ x -> x) & (❵❇ y -> ✭✮) ✐♥ f ❵❆ 3
: int
❼ Type of a variable is flow-invariant ❼
❼ ❼ ❼
❼
❼ Type of a variable is flow-invariant ❼ Flow sensitivity:
❼ ❼ ❼
❼
❼ Type of a variable is flow-invariant ❼ Flow sensitivity:
❼ Makes variable types less clear ❼ ❼
❼
❼ Type of a variable is flow-invariant ❼ Flow sensitivity:
❼ Makes variable types less clear ❼ Brittle to refactoring ❼
❼
❼ Type of a variable is flow-invariant ❼ Flow sensitivity:
❼ Makes variable types less clear ❼ Brittle to refactoring ❼ Doesn’t help that much
❼
❼ Type of a variable is flow-invariant ❼ Flow sensitivity:
❼ Makes variable types less clear ❼ Brittle to refactoring ❼ Doesn’t help that much
❼ Could be added later if needed
❼ In PL design, asymmetry can be good ❼
❼ ❼ ❼ ❼ ❼
❼ In PL design, asymmetry can be good ❼ Examples of asymmetry:
❼ ❼ ❼ ❼ ❼
❼ In PL design, asymmetry can be good ❼ Examples of asymmetry:
❼ Subtyping ❼ ❼ ❼ ❼
❼ In PL design, asymmetry can be good ❼ Examples of asymmetry:
❼ Subtyping ❼ Overriding ❼ ❼ ❼
❼ In PL design, asymmetry can be good ❼ Examples of asymmetry:
❼ Subtyping ❼ Overriding ❼ Multiple inheritance ❼ ❼
❼ In PL design, asymmetry can be good ❼ Examples of asymmetry:
❼ Subtyping ❼ Overriding ❼ Multiple inheritance ❼ Evaluation order ❼
❼ In PL design, asymmetry can be good ❼ Examples of asymmetry:
❼ Subtyping ❼ Overriding ❼ Multiple inheritance ❼ Evaluation order ❼ Module dependencies
❼ Onion projection prefers rightmost element ❼ ❼
❼
❵❆ ✐♥t
❼
❵❆ ✐♥t ❼ ❼
❼ Onion projection prefers rightmost element ❼ Not based on row typing ❼
❼
❵❆ ✐♥t
❼
❵❆ ✐♥t ❼ ❼
❼ Onion projection prefers rightmost element ❼ Not based on row typing ❼ Only presence information is pushed forward
❼
❵❆ ✐♥t
❼
❵❆ ✐♥t ❼ ❼
❼ Onion projection prefers rightmost element ❼ Not based on row typing ❼ Only presence information is pushed forward
❼ Type system can express “α has ❵❆ ✐♥t” ❼
❵❆ ✐♥t ❼ ❼
❼ Onion projection prefers rightmost element ❼ Not based on row typing ❼ Only presence information is pushed forward
❼ Type system can express “α has ❵❆ ✐♥t” ❼ But not “α only has ❵❆ ✐♥t”
❼ ❼
❼ Onion projection prefers rightmost element ❼ Not based on row typing ❼ Only presence information is pushed forward
❼ Type system can express “α has ❵❆ ✐♥t” ❼ But not “α only has ❵❆ ✐♥t”
❼ Upper bounds inferred from usage ❼
❼ Onion projection prefers rightmost element ❼ Not based on row typing ❼ Only presence information is pushed forward
❼ Type system can express “α has ❵❆ ✐♥t” ❼ But not “α only has ❵❆ ✐♥t”
❼ Upper bounds inferred from usage ❼ Monomorphic variant of TinyBang closure is
polynomial (vs. previous NP-complete result [Palsberg et al. ’03])
❼ For scripts, edit-compile-debug must be fast ❼ ❼
❼ ❼ ❼ ❼
❼ For scripts, edit-compile-debug must be fast ❼ Type constraint closure can be slow ❼
❼ ❼ ❼ ❼
❼ For scripts, edit-compile-debug must be fast ❼ Type constraint closure can be slow ❼ Solution:
❼ ❼ ❼ ❼
❼ For scripts, edit-compile-debug must be fast ❼ Type constraint closure can be slow ❼ Solution:
❼ Track differences between software versions ❼ ❼ ❼
❼ For scripts, edit-compile-debug must be fast ❼ Type constraint closure can be slow ❼ Solution:
❼ Track differences between software versions ❼ Delete constraints for removed code ❼ ❼
❼ For scripts, edit-compile-debug must be fast ❼ Type constraint closure can be slow ❼ Solution:
❼ Track differences between software versions ❼ Delete constraints for removed code ❼ Include constraints from new code ❼
❼ For scripts, edit-compile-debug must be fast ❼ Type constraint closure can be slow ❼ Solution:
❼ Track differences between software versions ❼ Delete constraints for removed code ❼ Include constraints from new code ❼ Perform closure again
❼ Typical type system limitations
❼ ❼
❼
❼
❼ Typical type system limitations
❼ Recursion limits contour creation ❼
❼
❼
❼ Typical type system limitations
❼ Recursion limits contour creation ❼ Flow-insensitivity
❼
❼
❼ Typical type system limitations
❼ Recursion limits contour creation ❼ Flow-insensitivity
❼ Syntactic limitations
❼
❼ Typical type system limitations
❼ Recursion limits contour creation ❼ Flow-insensitivity
❼ Syntactic limitations
❼ No string-to-label functionality
What will we want out of a compiler?
❼ Compiles scripts to native binaries (via LLVM) ❼
❼ ❼ ❼
❼
What will we want out of a compiler?
❼ Compiles scripts to native binaries (via LLVM) ❼ Optimizes layout using type information
❼ ❼ ❼
❼
What will we want out of a compiler?
❼ Compiles scripts to native binaries (via LLVM) ❼ Optimizes layout using type information
❼ No unnecessary boxing ❼ ❼
❼
What will we want out of a compiler?
❼ Compiles scripts to native binaries (via LLVM) ❼ Optimizes layout using type information
❼ No unnecessary boxing ❼ Reduce pointer arithmetic ❼
❼
What will we want out of a compiler?
❼ Compiles scripts to native binaries (via LLVM) ❼ Optimizes layout using type information
❼ No unnecessary boxing ❼ Reduce pointer arithmetic ❼ Definitely no runtime hashing
❼
What will we want out of a compiler?
❼ Compiles scripts to native binaries (via LLVM) ❼ Optimizes layout using type information
❼ No unnecessary boxing ❼ Reduce pointer arithmetic ❼ Definitely no runtime hashing
❼ Still path-sensitive across modules
What will we want out of a compiler?
❼ Compiles scripts to native binaries (via LLVM) ❼ Optimizes layout using type information
❼ No unnecessary boxing ❼ Reduce pointer arithmetic ❼ Definitely no runtime hashing
❼ Still path-sensitive across modules
How do we get this?
Why do we need a whole-program view?
❼ No declarations of types or module signatures ❼ ❼
Why do we need a whole-program view?
❼ No declarations of types or module signatures ❼ General layout for extensible data structures is
inefficient
❼
Why do we need a whole-program view?
❼ No declarations of types or module signatures ❼ General layout for extensible data structures is
inefficient
❼ So we must know what could arrive at each
call site
How can we live with ourselves?
❼ Intermediate work (constraint sets, etc.) can
be stored and reused
❼ ❼ ❼
How can we live with ourselves?
❼ Intermediate work (constraint sets, etc.) can
be stored and reused
❼ Coding to a module signature is limited; not all
interface semantics are typeable
❼ ❼
How can we live with ourselves?
❼ Intermediate work (constraint sets, etc.) can
be stored and reused
❼ Coding to a module signature is limited; not all
interface semantics are typeable
❼ Vast layout optimization potential ❼
How can we live with ourselves?
❼ Intermediate work (constraint sets, etc.) can
be stored and reused
❼ Coding to a module signature is limited; not all
interface semantics are typeable
❼ Vast layout optimization potential ❼ Shared libraries are still possible
❼ Standard approach: common layout form (as
C++)
❼
❼ ❼
❼ ❼
❼ Standard approach: common layout form (as
C++)
❼ Existing work handles flexible data structures
❼ ❼
❼ ❼
❼ Standard approach: common layout form (as
C++)
❼ Existing work handles flexible data structures
❼ A Calculus with Polymorphic and Polyvariant Flow
Types [Wells et al. ’02]
❼
❼ ❼
❼ Standard approach: common layout form (as
C++)
❼ Existing work handles flexible data structures
❼ A Calculus with Polymorphic and Polyvariant Flow
Types [Wells et al. ’02]
❼ A Polymorphic Record Calculus and Its
Compilation [Ohori ’95] ❼ ❼
❼ Standard approach: common layout form (as
C++)
❼ Existing work handles flexible data structures
❼ A Calculus with Polymorphic and Polyvariant Flow
Types [Wells et al. ’02]
❼ A Polymorphic Record Calculus and Its
Compilation [Ohori ’95] ❼ Onions: more flexible, new problems ❼
❼ Standard approach: common layout form (as
C++)
❼ Existing work handles flexible data structures
❼ A Calculus with Polymorphic and Polyvariant Flow
Types [Wells et al. ’02]
❼ A Polymorphic Record Calculus and Its
Compilation [Ohori ’95] ❼ Onions: more flexible, new problems ❼ Whole-program types will help us!
We have:
❼ A TinyBang interpreter ❼ ❼ ❼ ❼ ❼
We have:
❼ A TinyBang interpreter ❼ A TinyBang type system and soundness proof ❼ ❼ ❼ ❼
We have:
❼ A TinyBang interpreter ❼ A TinyBang type system and soundness proof ❼ Effective encodings for language features ❼ ❼ ❼
We have:
❼ A TinyBang interpreter ❼ A TinyBang type system and soundness proof ❼ Effective encodings for language features
We need:
❼ ❼ ❼
We have:
❼ A TinyBang interpreter ❼ A TinyBang type system and soundness proof ❼ Effective encodings for language features
We need:
❼ A TinyBang-to-LLVM compiler ❼ ❼
We have:
❼ A TinyBang interpreter ❼ A TinyBang type system and soundness proof ❼ Effective encodings for language features
We need:
❼ A TinyBang-to-LLVM compiler ❼ A BigBang metaprogramming system ❼
We have:
❼ A TinyBang interpreter ❼ A TinyBang type system and soundness proof ❼ Effective encodings for language features
We need:
❼ A TinyBang-to-LLVM compiler ❼ A BigBang metaprogramming system ❼ A layout calculus and optimization tool
We have:
❼ A TinyBang interpreter ❼ A TinyBang type system and soundness proof ❼ Effective encodings for language features
We need:
❼ A TinyBang-to-LLVM compiler ❼ A BigBang metaprogramming system ❼ A layout calculus and optimization tool
...