Casts and costs: harmonizing safety and performance in gradual typing

Abstract

Gradual typing allows programmers to use both static and dynamic typing in a single program. However, a well-known problem with sound gradual typing is that the interactions between static and dynamic code can cause significant performance degradation. These performance pitfalls are hard to predict and resolve, and discourage users from using gradual typing features. For example, when migrating to a more statically typed program, often adding a type annotation will trigger a slowdown that can be resolved by adding more annotations elsewhere, but since it is not clear where the additional annotations must be added, the easier solution is to simply remove the annotation. To address these problems, we develop: (1) a static cost semantics that accurately predicts the overhead of static-dynamic interactions in a gradually typed program, (2) a technique for efficiently inferring such costs for all combinations of inferrable type assignments in a program, and (3) a method for translating the results of this analysis into specific recommendations and explanations that can help programmers understand, debug, and optimize the performance of gradually typed programs. We have implemented our approach in Herder, a tool for statically analyzing the performance of different typing configurations for Reticulated Python programs. An evaluation on 15 Python programs shows that Herder can use this analysis to accurately and efficiently recommend type assignments that optimize the performance of these programs without sacrificing the safety guarantees provided by static typing.

Gradually structured data

“…The performance of gradually-typed languages is a research area in itself [Bauman et al 2017;Campora et al 2018;Greenman et al 2019;Herman et al 2010;Kuhlenschmidt et al 2019;Siek and Wadler 2010;Siek et al 2015b;Takikawa et al 2016], and we have so far not explored how to best implement gradually-structured data. First of all, the dynamic semantics derived with AGT as presented here are not space efficient: evidence transitivity checks accumulate in tail calls and open datatypes and dynamically-generated constructors will require more information at runtime.…”

Solver-based gradual type migration

“…We do this via soft constraints that penalize the number of non-trivial, syntactic coercions. Note that this is not the same as minimizing the number of coercions performed during evaluation, which is a harder problem (but see Campora et al [2018a]).…”

Variational satisfiability solving

“…Variational SAT solving is the latest in a line of work that uses the choice calculus to investigate variation as a computational phenomena. The choice calculus has been successfully applied to diverse areas of computer science, such as databases [4,5], graphics [28], data structures [30,49,61,69], type systems [14,15,20,21], error messages [17][18][19][20], and now satisfiability solving. Our use of choices is similar to the concept of facets [6] and faceted execution [7,50,58], which have been successfully applied to information-flow security and policy-agnostic programming.…”

“…More generally, any scenario that involves solving many related SAT problems, and where all of these problems are known or can be generated in advance, is a potential application for variational SAT solving. Such situations arise in program analysis [66], and especially in speculative program analyses that involve generating and exploring huge numbers of variations of a program, for example, as in counterfactual [17] and migrational [14,15] typing. Furthermore, we believe that variational solving provides a basis for such speculative analyses on feature models.…”