Is sound gradual typing dead?

Abstract

Programmers have come to embrace dynamically-typed languages for prototyping and delivering large and complex systems. When it comes to maintaining and evolving these systems, the lack of explicit static typing becomes a bottleneck. In response, researchers have explored the idea of gradually-typed programming languages which allow the incremental addition of type annotations to software written in one of these untyped languages. Some of these new, hybrid languages insert run-time checks at the boundary between typed and untyped code to establish type soundness for the overall system. With sound gradual typing, programmers can rely on the language implementation to provide meaningful error messages when type invariants are violated. While most research on sound gradual typing remains theoretical, the few emerging implementations suffer from performance overheads due to these checks. None of the publications on this topic comes with a comprehensive performance evaluation. Worse, a few report disastrous numbers. In response, this paper proposes a method for evaluating the performance of gradually-typed programming languages. The method hinges on exploring the space of partial conversions from untyped to typed. For each benchmark, the performance of the different versions is reported in a synthetic metric that associates runtime overhead to conversion effort. The paper reports on the results of applying the method to Typed Racket, a mature implementation of sound gradual typing, using a suite of real-world programs of various sizes and complexities. Based on these results the paper concludes that, given the current state of implementation technologies, sound gradual typing faces significant challenges. Conversely, it raises the question of how implementations could reduce the overheads associated with soundness and how tools could be used to steer programmers clear from pathological cases.

Big Code: New Opportunities for Improving Software Construction

“…We are currently working on improving decompilation using machine learning [11], and predicting the performance gain of adding type annotations to variables in a gradually typed program [12]. We also plan to build a web-based collaborative system to support a rule-based expert system based on the knowledge extracted from static program analysis, stored in graph databases.…”

“…One example is improving the decompilation process, learning from recurrent patterns that specific compilers use to generate binary code [11]. Another example is predicting the performance benefit of annotating the type of a variable in a gradually typed language, using regression techniques [12].…”

Semantics-driven interoperability between Scala.js and JavaScript

“…In Scala and in Scala.js, types are therefore only sound up to erasure. Even though erasure is often regarded as a liability, it gives Scala.js immunity against the common performance problems found in interoperability layers that check types at the borders [21]. Indeed, only the first-order type needs to be checked, which is a constant-time operation.…”

“…Dynamic checking of static contracts is also a recurring theme in gradual typing [20,22], although the runtime semantic difference issue does not apply in those cases. Gradually typed systems often suffer from performance problems [21] due to either deep type tests or towers of wrappers. Scala.js avoids those issues by blending type tests related to interoperability borders with those necessary due to erased generic types in Scala.…”

Benefits of session types for software development

“…Otherwise there is the risk of developing something that may not be quite right or suitable for its purpose. An example of this can be seen in gradual typing, another very active area of research, which is now having its practicality called into question [21]. By identifying which designs and implementations help or hinder programmers, we can improve them to help developers use session type effectively.…”