How to Evaluate Blame for Gradual Types, Part 2

Lukas Lazarek, Ben Greenman, Matthias Felleisen, Christos Dimoulas

Research output: Contribution to journalArticlepeer-review

3 Scopus citations

Abstract

Equipping an existing programming language with a gradual type system requires two major steps. The first and most visible one in academia is to add a notation for types and a type checking apparatus. The second, highly practical one is to provide a type veneer for the large number of existing untyped libraries; doing so enables typed components to import pieces of functionality and get their uses type-checked, without any changes to the libraries. When programmers create such typed veneers for libraries, they make mistakes that persist and cause trouble. The question is whether the academically investigated run-Time checks for gradual type systems assist programmers with debugging such mistakes. This paper provides a first, surprising answer to this question via a rational-programmer investigation: run-Time checks alone are typically less helpful than the safety checks of the underlying language. Combining Natural run-Time checks with blame, however, provides significantly superior debugging hints.

Original languageEnglish (US)
Article number194
Pages (from-to)159-186
Number of pages28
JournalProceedings of the ACM on Programming Languages
Volume7
Issue numberICFP
DOIs
StatePublished - Aug 30 2023

Keywords

  • blame
  • gradual typing

ASJC Scopus subject areas

  • Software
  • Safety, Risk, Reliability and Quality

Fingerprint

Dive into the research topics of 'How to Evaluate Blame for Gradual Types, Part 2'. Together they form a unique fingerprint.

Cite this