Migrating gradual types

Abstract

Gradual typing allows programs to enjoy the benefits of both static typing and dynamic typing. While it is often desirable to migrate a program from more dynamically-typed to more statically-typed or vice versa, gradual typing itself does not provide a way to facilitate this migration. This places the burden on programmers who have to manually add or remove type annotations. Besides the general challenge of adding type annotations to dynamically typed code, there are subtle interactions between these annotations in gradually typed code that exacerbate the situation. For example, to migrate a program to be as static as possible, in general, all possible combinations of adding or removing type annotations from parameters must be tried out and compared.In this paper, we address this problem by developing migrational typing, which efficiently types all possible ways of adding or removing type annotations from a gradually typed program. The typing result supports automatically migrating a program to be as static as possible, or introducing the least number of dynamic types necessary to remove a type error. The approach can be extended to support user-defined criteria about which annotations to modify. We have implemented migrational typing and evaluated it on large programs. The results show that migrational typing scales linearly with the size of the program and takes only 2ś4 times longer than plain gradual typing.

What is decidable about gradual types?

“…Comparison. Our tool uses the same input format as the tool that accompanies the paper by Campora et al [2018]. This enables a head-to-head comparison of our tool and their tool, for our benchmarks.…”

“…Notice that for every benchmark, the type produced by their tool is ⊑-related to the type produced by our tool. For six benchmarks, the types are different, for three benchmarks the types are the same, and for one benchmark, no maximal migration exists but the tool from [Campora et al 2018] produces a type anyway. The differences highlight that the tool from [Campora et al 2018] may produce non-maximal migrations.…”

Casts and costs: harmonizing safety and performance in gradual typing

“…However, often the most static migration of a gradually typed program is not unique, and so the programmer wants to pick the most performant migration amongst the set of possibilities. The following program, adapted from [Campora et al 2018], illustrates the non-uniqueness of most-static migrations. In this example, a type annotation may be added to the parameter fixed or to widthFunc, but not to both.…”

“…if (fixed): widthFunc(fixed) else: widthFunc(5) Campora et al [2018] reported hundreds of different ways to maximize static typing in larger programs. Since each of the most-static migrations may have significantly different performance profiles, it is important that the programmer can make a rational selection among them.…”

“…(b) Each node indicates whether the eval_A, part_A_times_u, and part_At_times_u functions are annotated (filled oval) or not (unfilled). programs is difficult [Campora et al 2018; and can cause reliability and performance issues [Allende et al 2014]. In particular, Takikawa et al [2016] observed that adding type annotations can cause a more than 100 times slowdown in Typed Racket.…”