The root cause of blame: contracts for intersection and union types

Williams, Jack; Morris, John; Wadler, Philip

doi:10.1145/3276504

Cited by 10 publications

(12 citation statements)

References 30 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Blame also plays an important role in gradual typing [Ahmed et al 2009;Garcia 2013;Igarashi et al 2017;Siek et al 2009Siek et al , 2015aSiek and Wadler 2010;Vitousek et al 2014;Williams et al 2018]. We anticipate that the experimental design we present is also applicable in that setting to explore and evaluate design strategies.…”

Section: Contracts and Blamementioning

confidence: 86%

Does blame shifting work?

Lazarek

King

Sundar

et al. 2019

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

Contract systems, especially of the higher-order flavor, go hand in hand with blame. The pragmatic purpose of blame is to narrow down the code that a programmer needs to examine to locate the bug when the contract system discovers a contract violation. Or so the literature on higher-order contracts claims. In reality, however, there is neither empirical nor theoretical evidence that connects blame with the location of bugs. The reputation of blame as a tool for weeding out bugs rests on anecdotes about how programmers use contracts to shift blame and their attention from one part of a program to another until they discover the source of the problem. This paper aims to fill the apparent gap and shed light to the relation between blame and bugs. To that end, we introduce an empirical methodology for investigating whether, for a given contract system, it is possible to translate blame information to the location of bugs in a systematic manner. Our methodology is inspired by how programmers attempt to increase the precision of the contracts of a blamed component in order to shift blame to another component, which becomes the next candidate for containing the bug. In particular, we construct a framework that enables us to ask for a contract system whether (i) the process of blame shifting causes blame to eventually settle to the component that contains the bug; and (ii) every shift moves blame łcloserž to the faulty component. Our methodology offers a rigorous means for evaluating the pragmatics of contract systems, and we employ it to analyze Racket's contract system. Along the way, we uncover subtle points about the pragmatic meaning of contracts and blame in Racket: (i) the expressiveness of Racket's off-the-shelf contract language is not sufficient to narrow down the blamed portion of the code to the faulty component in all cases; and (ii) contracts that trigger state changes (even unexpectedly, perhaps in the runtime system's data structures or caches) interfere with program evaluation in subtle ways and thus blame shifting can lead programmers on a detour when searching for a bug. These points highlight how evaluations such as ours suggest fixes to language design. CCS Concepts: • Theory of computation → Program specifications; • Software and its engineering → Empirical software validation.

show abstract

Section: Contracts and Blamementioning

confidence: 86%

Does blame shifting work?

Lazarek

King

Sundar

et al. 2019

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

show abstract

“…The wrappers monitor interactions between a library and a client, and if a failure occurs then blame indicates whether it is the library or the client that has failed to conform to the declared types. TypeScript TNG relies upon an equivalent of the rule for casting functions in λB, but goes beyond our work in supporting union types (Williams et al, 2017(Williams et al, , 2018. Abadi et al (1991) study an early notion of type Dynamic.…”

Section: Systems That Use Gradual Typingmentioning

confidence: 98%

Blame and coercion: Together again for the first time

Siek¹,

Thiemann²,

Wadler³

2021

J. Funct. Prog.

Self Cite

View full text Add to dashboard Cite

C#, Dart, Pyret, Racket, TypeScript, VB: many recent languages integrate dynamic and static types via gradual typing. We systematically develop four calculi for gradual typing and the relations between them, building on and strengthening previous work. The calculi are as follows: $\lambda{B}$ , based on the blame calculus of Wadler and Findler (2009); $\lambda{C}$ , inspired by the coercion calculus of Henglein (1994); $\lambda{S}$ inspired by the space-efficient calculus of Herman, Tomb, and Flanagan (2006); and $\lambda{T}$ based on the threesome calculus of Siek and Wadler (2010). While $\lambda{B}$ and $\lambda{T}$ are little changed from previous work, $\lambda{C}$ and $\lambda{S}$ are new. Together, $\lambda{B}$ , $\lambda{C}$ , $\lambda{S}$ , and $\lambda{T}$ provide a coherent foundation for design, implementation, and optimization of gradual types. We define translations from $\lambda{B}$ to $\lambda{C}$ , from $\lambda{C}$ to $\lambda{S}$ , and from $\lambda{S}$ to $\lambda{T}$ . Much previous work lacked proofs of correctness or had weak correctness criteria; here we demonstrate the strongest correctness criterion one could hope for, that each of the translations is fully abstract. Each of the calculi reinforces the design of the others: $\lambda{C}$ has a particularly simple definition, and the subtle definition of blame safety for $\lambda{B}$ is justified by the simple definition of blame safety for $\lambda{C}$ . Our calculus $\lambda{S}$ is implementation-ready: the first space-efficient calculus that is both straightforward to implement and easy to understand. We give two applications: first, using full abstraction from $\lambda{C}$ to $\lambda{S}$ to establish an equational theory of coercions; and second, using full abstraction from $\lambda{B}$ to $\lambda{S}$ to easily establish the Fundamental Property of Casts, which required a custom bisimulation and six lemmas in earlier work.

show abstract

“…Therefore, the question of bringing union to contracts is natural, and have indeed been studied (e.g. [14,22]).…”

Section: Unions a Union Typementioning

confidence: 99%

“…In particular, both Type-Script [9] and MyPy [7], use union types to model the frequent practice to use the value null (None in Python) to represent an absent optional value. This is why the gradual typing literature, concerned with formalising the interplay between static and dynamic type systems, has been quite interested in union types [10,14,17,20,22].…”

Section: Introductionmentioning

confidence: 99%

Union and intersection contracts are hard, actually

Freund,

Hamdaoui,

Spiwack

2021

Preprint

View full text Add to dashboard Cite

Union and intersection types are a staple of gradually typed language such as TypeScript. While it's long been recognized that union and intersection types are difficult to verify statically, it may appear at first that the dynamic part of gradual typing is actually pretty simple.It turns out however, that in presence of higher-order contracts union and intersection are deceptively difficult. The literature on higher-order contracts with union and intersection, while keenly aware of the fact, doesn't really explain why. We point and illustrate the problems and tradeoffs inherent to union and intersection contracts, via example and a survey of the literature. CCS Concepts:• General and reference → Surveys and overviews; • Software and its engineering → Language features; Software verification and validation.

show abstract

The root cause of blame: contracts for intersection and union types

Cited by 10 publications

References 30 publications

Does blame shifting work?

Does blame shifting work?

Blame and coercion: Together again for the first time

Union and intersection contracts are hard, actually

Contact Info

Product

Resources

About