Migrating gradual types

Campora, John Peter; Chen, Sheng; Erwig, Martin; Walkingshaw, Eric

doi:10.1145/3158103

Cited by 17 publications

(41 citation statements)

References 36 publications

(54 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…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.…”

Section: Implementation and Experimental Resultsmentioning

confidence: 99%

“…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.…”

Section: Benchmarkmentioning

confidence: 99%

See 1 more Smart Citation

What is decidable about gradual types?

Migeed

Palsberg

2019

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

Programmers can use gradual types to migrate programs to have more precise type annotations and thereby improve their readability, efficiency, and safety. Such migration requires an exploration of the migration space and can benefit from tool support, as shown in previous work. Our goal is to provide a foundation for better tool support by settling decidability questions about migration with gradual types. We present three algorithms and a hardness result for deciding key properties and we explain how they can be useful during an exploration. In particular, we show how to decide whether the migration space is finite, whether it has a top element, and whether it is a singleton. We also show that deciding whether it has a maximal element is NP-hard. Our implementation of our algorithms worked as expected on a suite of microbenchmarks.We can use those properties to classify programs into five increasingly larger sets. Figure 1 illustrates both how those sets are nested (top half) and the migration possibilities (bottom half). Each of (a)ś(e) shows the original program as a circle and, above it, possible migrations; maximal migrations are shown as bold circles.Our contributions. We present algorithms (with names in bold below) and a hardness result for deciding the four questions above for the gradually typed λ-calculus [Siek and Taha 2006]. Singleton problem:decidable in O(n 2 ) time (Theorem 3.5) Singleton Checker Top-choice problem: decidable in EXPTIME (Theorem 5.3) Top-Choice Checker Finiteness problem: decidable in EXPTIME (Theorem 4.11) Finiteness Checker Maximality problem: NP-hard (Theorem 6.1).

show abstract

Section: Implementation and Experimental Resultsmentioning

confidence: 99%

Section: Benchmarkmentioning

confidence: 99%

What is decidable about gradual types?

Migeed

Palsberg

2019

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

show abstract

“…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.…”

Section: Program Migration Scenariosmentioning

confidence: 99%

“…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.…”

Section: Program Migration Scenariosmentioning

confidence: 99%

“…(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.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Casts and costs: harmonizing safety and performance in gradual typing

Campora

Chen

Walkingshaw

2018

Proc. ACM Program. Lang.

Self Cite

View full text Add to dashboard Cite

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.

show abstract

Migrating gradual types

Campora¹,

Chen²,

Erwig³

et al. 2022

J. Funct. Prog.

Self Cite

View full text Add to dashboard Cite

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 replacing dynamic types with fully static types for 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.

show abstract

Migrating gradual types

Cited by 17 publications

References 36 publications

What is decidable about gradual types?

What is decidable about gradual types?

Casts and costs: harmonizing safety and performance in gradual typing

Migrating gradual types

Contact Info

Product

Resources

About