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.
Thu 7 SepDisplayed time zone: Pacific Time (US & Canada) change
13:30 - 14:30 | Blame and educationICFP Papers and Events at B - Fifth Avenue Chair(s): Benjamin C. Pierce University of Pennsylvania | ||
13:30 30mTalk | How to Evaluate Blame for Gradual Types, Part 2 ICFP Papers and Events Lukas Lazarek Northwestern University, Ben Greenman Brown University, Matthias Felleisen PLT @ Northeastern University, Christos Dimoulas PLT @ Northwestern University DOI | ||
14:00 30mTalk | What Happens When Students Switch (Functional) Languages (Experience Report)RemoteExperience Report ICFP Papers and Events Kuang-Chen Lu Brown University, USA, Shriram Krishnamurthi Brown University, United States, Kathi Fisler Brown University, Ethel Tshukudu University of Botswana DOI |