Type Checking and Inference for Dynamic Languages

Object-oriented dynamic languages such as Ruby, Python, and JavaScript provide rapid code development and a high degree of flexibility and agility to the programmer. Some of the their main features include dynamic typing and metaprogramming. In dynamic typing, programmers do not declare or cast types, and types are not known until run time. In addition, an object’s suitability is determined by its methods, as opposed to its class. Metaprogramming dynamically generates code as the program executes, which means that methods and classes can be added and modified at run-time. These features are powerful but lead to a major drawback of dynamic languages: the lack of static types means that type errors can remain latent long into the software development process or even into deployment, especially in the presence of metaprogramming. To bring the benefits of static types to dynamic languages, I present three pieces of work. First, I present the Ruby Type Checker (rtc), a tool that adds type check- ing to Ruby. Rtc addresses the issue of latent type errors by checking all types during run time at method entrance and exit. Thus it checks types later than a purely static system, but earlier than a traditional dynamic type system. Rtc is implemented as a Ruby library and supports type annotations on classes, methods, and objects. Rtc provides a rich type language that includes union and intersection types, higher-order (block) types, and parametric polymorphism, among other features. We applied rtc to several apps and found it effective at checking types. Second, I present Hummingbird, a just-in-time static type checker for dy- namic languages. Hummingbird also prevents latent type errors, and type checks Ruby code even in the presence of metaprogramming, which is not handled by rtc. In Hummingbird, method type signatures are gathered dynamically at run-time, as those methods are created. When a method is called, Hummingbird statically type checks the method body against current type signatures. Thus, Hummingbird provides thorough static checks on a per-method basis, while also allowing arbitrarily complex metaprogramming. We applied Hummingbird to six apps, including three that use Ruby on Rails, a powerful framework that relies heavily on metaprogramming. We found that all apps type check successfully using Hummingbird, and that Hummingbird’s performance overhead is reasonable. Lastly, I present a practical type inference system for Ruby. Although both rtc and Hummingbird are very effective tools for type checking, the programmer must provide the type annotations on the application methods, which may be a time-consuming and error-prone process. Type inference is a generalization of type checking that automatically infers types while performing checking. However, standard type inference often infers types that are overly permissive compared to what a programmer might write, or contain no useful information, such as the bottom type. I first present a standard type inference system for Ruby, where constraints on a method is statically gathered as soon as the method is invoked at run-time, and types are resolved after all constraints have been gathered on all methods. I then build a practical type inference system on top of the standard type inference system. The goal of my practical type inference system is to infer types that are concise and include actual classes when appropriate. Finally, I evaluate my practical type inference system on three Ruby apps and show it to be very effective compared to the standard type inference system. In sum, I believe that rtc, Hummingbird, and the practical type inference system all take strong steps forward in bringing the benefits of static typing to dynamic languages

Towards More Expressive and Usable Types for Dynamic Languages

Many popular programming languages, including Ruby, JavaScript, and Python, feature dynamic type systems, in which types are not known until runtime. Dynamic typing provides the programmer with flexibility and allows for rapid program development. In contrast, static type systems, found in languages like C++ and Java, help catch errors early during development, enforce invariants as programs evolve, and provide useful documentation via type annotations. Many researchers have explored combining these contrasting paradigms, seeking to marry the flexibility of dynamic types with the correctness guarantees and documentation of static types. However, many challenges remain in this pursuit: programmers using dynamic languages may wish to verify more expressive properties than basic type safety; operations for commonly used libraries, such as those for databases and heterogeneous data structures, are difficult to precisely type check; and type inference---the process of automatically deducingthe types of methods and variables in a program---often produces type annotations that are complex and verbose, and thus less usable for the programmer. To address these issues, I present four pieces of work that aim to increase the expressiveness and usability of static types for dynamic languages. First, I present RTR, a system that adds refinement types to Ruby: basic types extended with expressive predicates. RTR uses assume-guarantee reasoning and a novel idea called just-in-time verification---in which verification is deferred until runtime---to handle dynamic program features such as mixins and metaprogramming. We found RTR was useful for verifying key methods in six Ruby programs. Second, I present CompRDL, a Ruby type system that allows library method type signatures to include type-level computations(or comp types). Comp types can be used to precisely type check database queries, as well as operations over heterogeneous data structures like arrays and hashes. We used CompRDL to type check methods from six Ruby programs, enabling us to check more expressive properties, with fewer manually inserted type casts, than was possible without comp types. Third, I present InferDL, a Ruby type inference system that aims to produce usable type annotations. Becausethe types inferred by standard, constraint-based inference are often complex and less useful to the programmer, InferDL complements constraints with configurable heuristics that aim to produce more usable types. We applied InferDL to four Ruby programs with existing type annotations and found that InferDL inferred 22% more types that matched the prior annotations compared to standard inference. Finally, I present SimTyper, a system that builds on InferDL by using a novel machine learning-based technique called type equality prediction. When standard and heuristic inference produce a non-usable type for a position (argument/return/variable), we use a deep similarity network to compare that position to other positions with usable types. If the network predicts that two positions have the same type, we guess the usable type in place of the non-usable one, and check the guess against constraints to ensure soundness. We evaluated SimTyper on eight Ruby programs with prior annotations and found that, compared to standard inference, SimTyper finds 69% more types that match programmer-written annotations. In sum, I claim that RTR, CompRDL, InferDL, and SimTyper represent promising steps towards more expressive and usable types for dynamic languages

Dynamically typed languages

Dynamically typed languages such as Python and Ruby have experienced a rapid grown in popularity in recent times. However, there is much confusion as to what makes these languages interesting relative to statically typed languages, and little knowledge of their rich history. In this chapter I explore the general topic of dynamically typed languages, how they differ from statically typed languages, their history, and their defining features

Interprocedural Type Specialization of JavaScript Programs Without Type Analysis

Dynamically typed programming languages such as Python and JavaScript defer type checking to run time. VM implementations can improve performance by eliminating redundant dynamic type checks. However, type inference analyses are often costly and involve tradeoffs between compilation time and resulting precision. This has lead to the creation of increasingly complex multi-tiered VM architectures. Lazy basic block versioning is a simple JIT compilation technique which effectively removes redundant type checks from critical code paths. This novel approach lazily generates type-specialized versions of basic blocks on-the-fly while propagating context-dependent type information. This approach does not require the use of costly program analyses, is not restricted by the precision limitations of traditional type analyses. This paper extends lazy basic block versioning to propagate type information interprocedurally, across function call boundaries. Our implementation in a JavaScript JIT compiler shows that across 26 benchmarks, interprocedural basic block versioning eliminates more type tag tests on average than what is achievable with static type analysis without resorting to code transformations. On average, 94.3% of type tag tests are eliminated, yielding speedups of up to 56%. We also show that our implementation is able to outperform Truffle/JS on several benchmarks, both in terms of execution time and compilation time.Comment: 10 pages, 10 figures, submitted to CGO 201