Position Paper: Dynamically Inferred Types for Dynamic Languages

Over the past few years we have been developing Diamondback Ruby (DRuby), a tool that brings static type inference to Ruby, a dynamically typed object-oriented language. Developing DRuby required creating a Ruby front-end, which was extremely challenging: like other dynamic languages, Ruby has a complex, yet poorly documented syntax and semantics, which we had to carefully reverse-engineer. Writing our front-end took well over a year, and now that Ruby 1.9 is available, we are faced with the daunting prospect of significant additional effort to discover how the language has changed, and to extend our front-end accordingly. We suspect that maintaining a static analysis system for other dynamic languages, such as Perl or Python, is similarly daunting. To remedy this situation, we recently introduced a new program analysis technique for dynamic languages: constraint-based dynamic type inference, which uses information gathered from dynamic runs to infer static types [1]. More precisely , at run-time we introduce type variables for fields, method arguments, and method return values. As values are passed to those positions, we dynamically wrap them in proxy objects to track the associated type variables. We also allow trusted type annotations for methods, which are stored in Class objects. As wrapped values are used, we generate subtyping constraints on the associated type variables. We solve those constraints at the end of one or more program runs, which produces a satisfying type assignment, if one exists. Importantly, despite relying on dynamic runs, we can prove a soundness theorem: if the dynamic runs from which types are inferred cover every path in the control-flow graph (CFG) of every method of a class, then the inferred types for that class's fields and methods are sound for all possible runs. Note this coverage criterion is in contrast to requiring that every program path is covered. We have implemented this technique for Ruby, as a tool called Rubydust (where " dust " stands for dynamic unraveling of static types). An important property of Rubydust is that it requires no front-end; in fact, it is a Ruby library that is loaded at run-time just like any other library. To operate, Rubydust uses Ruby's rich introspection features to wrap objects, intercept method calls, and store and retrieve any type annotations supplied by the programmer. Thus far, we have run Rubydust on a number of small programs, and have found that Rubydust produces correct, readable types. We believe that …