A spectrum of type soundness and performance

Greenman, Ben; Felleisen, Matthias

doi:10.1145/3236766

Cited by 29 publications

(33 citation statements)

References 80 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Second, the design of Transient represents a rather different trade-off. The runtime cost of types can be much lower than Natural in programs that mix typed and untyped code [Greenman and Felleisen 2018], but Transient types offer few guarantees to programmers. The type soundness theorem for Transient ensures only the top-level shape of values in typed code.…”

Section: Discussion: the Trade-off Between The Precision And Cost Of mentioning

confidence: 99%

“…A wrapper approach protects untyped code from incorrect types, and a first-order approach does not. While Greenman and Felleisen [2018] point out this difference with examples, they do not characterize it. This paper offers an explanation in terms of complete monitoring .…”

Section: Type Soundness Is Not Enoughmentioning

confidence: 94%

“…Our model builds on the previous work of Greenman and Felleisen [2018] who, in turn, employ Matthews and Findler [2009]'s multi-language framework for modeling the syntax, types, and semantics of a mixed-typed language. In particular, we interpret one "surface" syntax and mixed type system (figure 3) in three different ways.…”

Section: The Model: Syntax and Typesmentioning

confidence: 99%

“…[2018] compare different gradual typing systems as different translations from one surface language to one core language; they do not use theorems to characterize the difference in type soundness. Greenman and Felleisen [2018] interpret one gradual typing systems as several different semantics for a common surface language; their theorems establish distinct type soundness properties. present an axiomatic theory of gradual typing and prove that only the Natural semantics satisfies all the axioms.…”

Section: Related Workmentioning

confidence: 99%

“…Greenman and Felleisen [2018] demonstrated that Typed Racket and Transient Reticulated Python satisfy different type soundness theorems. This paper shows that these languages also differ in how they protect untyped code from faulty type specifications.…”

Section: Complete Monitoring Is Neededmentioning

confidence: 99%

See 4 more Smart Citations

Complete monitors for gradual types

Greenman

Felleisen

Dimoulas³

2019

Proc. ACM Program. Lang.

Self Cite

View full text Add to dashboard Cite

In the context of gradual typing, type soundness guarantees the safety of typed code. When untyped code fails to respect types, a runtime check finds the discrepancy. As for untyped code, type soundness makes no promises; it does not protect untyped code from mistakes in type specifications and unwarranted blame. To address the asymmetry, this paper adapts complete monitoring from the contract world to gradual typing. Complete monitoring strengthens plain soundness into a guarantee that catches problems with faulty type specifications. Furthermore, a semantics that satisfies complete monitoring can easily pinpoint the conflict between a type specification and a value. For gradual typing systems that fail complete monitoring, the technical framework provides a source-of-truth to assess the quality of blame.

show abstract

Section: Discussion: the Trade-off Between The Precision And Cost Of mentioning

confidence: 99%

Section: Type Soundness Is Not Enoughmentioning

confidence: 94%

Section: The Model: Syntax and Typesmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Section: Complete Monitoring Is Neededmentioning

confidence: 99%

See 3 more Smart Citations

Complete monitors for gradual types

Greenman

Felleisen

Dimoulas³

2019

Proc. ACM Program. Lang.

Self Cite

View full text Add to dashboard Cite

show abstract

Achieving Safety Incrementally with Checked C

Ruef

Lampropoulos

Sweet

et al. 2019

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Checked C is a new effort working toward a memory-safe C. Its design is distinguished from that of prior efforts by truly being an extension of C: Every C program is also a Checked C program. Thus, one may make incremental safety improvements to existing codebases while retaining backward compatibility. This paper makes two contributions. First, to help developers convert existing C code to use so-called checked (i.e., safe) pointers, we have developed a preliminary, automated porting tool. Notably, this tool takes advantage of the flexibility of Checked C's design: The tool need not perfectly classify every pointer, as required of prior all-or-nothing efforts. Rather, it can make a best effort to convert more pointers accurately, without letting inaccuracies inhibit compilation. However, such partial conversion raises the question: If safety violations can still occur, what sort of advantage does using Checked C provide? We draw inspiration from research on migratory typing to make our second contribution: We prove a blame property that renders so-called checked regions blameless of any run-time failure. We formalize this property for a core calculus and mechanize the proof in Coq.

show abstract

GATE: Gradual Effect Types

Wadler

2021

Lecture Notes in Computer Science

View full text Add to dashboard Cite

A spectrum of type soundness and performance

Cited by 29 publications

References 80 publications

Complete monitors for gradual types

Complete monitors for gradual types

Achieving Safety Incrementally with Checked C

GATE: Gradual Effect Types

Contact Info

Product

Resources

About