Gradual Typing

Presenter: Raj scribe: Cherif

Date: 2007/10/22

Notes

• This work was done by Jeremy Siek and Walid Taha in 2006
• Dynamic vs Static typing
  • Each has its benefits, but can we combine both?
    • Migrate from Static to dynamic (introduce "Dynamic" type)
    • Migrate from dynamic to static (optional type parameters)
• Gradual Typing
  • Gradual migration from dynamic to static by adding optional type annotations to dynamically typed languages
• Contributions:
  • Presents a formal type system supporting gradual typing in functional languages
  • prove:
    • Fully annotated programs are equivalent to Simply Typed Lambda Calculus (STLC)
    • Partially annotated programs don't hurt performance
• Type consistency
  • Types have both known and unknown types
  • Unknown type has type ?
  • Types consistent with themselves and ?
  • Reflexive, symmetric but non-transitive.
• Gradually typed Lambda Calculus (GTLC)
  • Add ? type to STLC and allow lambda's to be optionally annotated by the their type
  • Extended type system
• First theorem:
  • For fully annotated terms, a GTLC program is equivalent to the type corresponding STLC program
• Semantics of the gradually typed lambda calculus
  • Two steps: converts GTLC to STLC, and then evaluate intermediate language
  • Inserts casts based on types. Example:

    ((lambda (x) (succ x)) #t)

which generates

    ((lambda (x:?) (succ <number>x)) <?>#t)

which reduces to a runtime cast error.

• Other properties:
  • Canonical forms lemma
• Type preservation
  • expansion and contraction do not change types
  • substitution preserves types
  • soundness of evaluation

Discussion:

• Naive type-inference at this level can't work exactly because there are difficulties with polymorphism.
• Angela:
  • What if you have something in the middle between a fully annotated program and a gradually typed program?
  • Raj: Partially typed program might improve the performance but it will not hurt performance.
• Angela:
  • what if we have two applications: e1 e2 and e1 e3 where e1:? and e2:t2 and e3:t3 and t2 not consistent with t3, will the type checker detect the problem?
  • Raj: No, this will produce a run-time error
  • Greg: This might not be wrong for dynamic language where e1 might be parametric
• Daniel:
  • How do they implement that?
  • Raj: It is not implemented on a practical language in this paper
• Greg:
  • Do they talk about other approaches? are there any?
  • Raj: they talk about quasi-typing that appears to allow some programs that should not be allowed
• Angela:
  • what did you mean in slide 2 when you said that "add dynamic type to static languages"
  • Raj: This is close to the normal way of implementing dynamic languages: It adds a dynamic type and when x has type dynamic, it does a case select.
• Cherif:
  • There is a typing rule for application e1 e2 where the type of e1 is known to be t1->t2 and another rule where the type of e1 is ? so what happens in the cases where the type of e1 is partially known like in ?->t2 or in t1->? ?
  • Greg: This is covered by the first case since t1 and t2 can be anything including ?
• Greg:
  • Did he present semantics for this?
  • Raj: Yes but it is too big to present on slides
• Greg:
  • Does he perform a check on something like assigning to something of type ref ?
  • Blake: It will succeed, just like it would in any dynamic language.