Sound gradual typing is nominally alive and well

Bringing the bene ts of gradual typing to a language with parametric polymorphism like System F, while preserving relational parametricity, has proven extremely challenging: rst a empts were formulated a decade ago, and several designs were recently proposed. Among other issues, these proposals can however signal parametricity errors in unexpected situations, and improperly handle type instantiations when imprecise types are involved. ese observations further suggest that existing polymorphic cast calculi are not well suited for supporting a gradual counterpart of System F. Consequently, we revisit the challenge of designing a gradual language with explicit parametric polymorphism, exploring the extent to which the Abstracting Gradual Typing methodology helps us derive such a language, GSF. We present the design and metatheory of GSF, and provide a reference implementation. In addition to avoiding the uncovered semantic issues, GSF satis es all the expected properties of a gradual parametric language, save for one property: the dynamic gradual guarantee, which was le as conjecture in all prior work, is here proven to be simply incompatible with parametricity. We nevertheless establish a weaker property that allows us to disprove several claims about gradual free theorems, clarifying the kind of reasoning supported by gradual parametricity.

Section: Related Workmentioning

confidence: 99%

Gradual parametricity, revisited

Toro

Labrada

Tanter

2019

“…work has addressed the problem through new languages with more efficient gradually typed semantics [Muehlboeck and Tate 2017;Vitousek et al 2017] and through new implementation techniques for existing languages [Bauman et al 2017;Richards et al 2017]. There are two main differences between our work and previous efforts: First, our approach does not require changes to existing gradually typed languages or implementations; it works with the prevailing implementation technique of translating a typed variant of a language into an underlying untyped language.…”

Section: :7mentioning

confidence: 99%

“…The Nom programming language [Muehlboeck and Tate 2017] addresses it by designing the static and dynamic semantics for a gradually typed language from the ground up instead of adding gradual typing to an existing language. This helps reduce the overhead of running casts.…”

Section: Gradual Typing Performancementioning

confidence: 99%

Casts and costs: harmonizing safety and performance in gradual typing

Campora

Chen

Walkingshaw

2018

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.

“…2017]. A second approach is to guard the boundaries between typed and untyped regions with first-order checks [Muehlboeck and Tate 2017;Rastogi et al 2015;Roberts et al 2018;Vitousek et al 2017;Wrigstad et al 2010]. A third approach is to enforce types with higher-order contracts [Allende et al 2013;Williams et al 2017].…”

mentioning

confidence: 99%

“…One alternative is to use types only for static analysis, and ignore the question of runtime overhead [Bierman et al 2014;Bracha and Griswold 1993;Chaudhuri et al 2017]. Another is to design a new language with the flexibility of dynamic typing, but where every value comes with an intrinsic type [Muehlboeck and Tate 2017;Rastogi et al 2015;Richards et al 2015;Wrigstad et al 2010]. 4 Finally, a third approach is to offer weaker soundness and blame guarantees [Roberts et al 2018;Vitousek et al 2017].…”

mentioning

confidence: 99%

Collapsible contracts: fixing a pathology of gradual typing

Feltey¹,

Greenman

Scholliers

et al. 2018

The promise of gradual typing is that programmers should get the best of both worlds: the static guarantees of static types, and the dynamic flexibility of untyped programming. This is an enticing benefit, but one that, in practice, may carry significant costs. Significant enough, in fact, to threaten the very practicality of gradual typing; slowdowns as high as 120x are reported as arising from gradual typing. If one examines these results closely, though, it becomes clear that the costs of gradual typing are not evenly distributed. Indeed, while mixing typed and untyped code almost invariably carries non-trivial costs, many truly deal-breaking slowdowns exhibit pathological performance. Unfortunately, the very presence of these pathological casesÐand therefore the possibility of hitting them during developmentÐmakes gradual typing a risky proposition in any setting that even remotely cares about performance. This work attacks one source of large overheads in these pathological cases: an accumulation of contract wrappers that perform redundant checks. The work introduces a novel strategy for contract checkingÐ collapsible contractsÐwhich eliminates this redundancy for function and vector contracts and drastically reduces the overhead of contract wrappers. We implemented this checking strategy as part of the Racket contract system, which is used in the Typed Racket gradual typing system. Our experiments show that our strategy successfully brings a class of pathological cases in line with normal cases, while not introducing an undue overhead to any of the other cases. Our results also show that the performance of gradual typing in Racket remains prohibitive for many programs, but that collapsible contracts are one essential ingredient in reducing the cost of gradual typing.