Software Open Access

Knowing When to Ask: Artifact

Arjen Rouvoet; Hendrik van Antwerpen; Casper Bach Poulsen; Robbert Krebbers; Eelco Visser


Citation Style Language JSON Export

{
  "publisher": "Zenodo", 
  "DOI": "10.5281/zenodo.4068065", 
  "title": "Knowing When to Ask: Artifact", 
  "issued": {
    "date-parts": [
      [
        2020, 
        10, 
        6
      ]
    ]
  }, 
  "abstract": "<p>There is a large gap between the specification of type systems and the<br>\nimplementation of their type checkers, which impedes reasoning about the<br>\nsoundness of the type checker with respect to the specification.&nbsp; A vision to<br>\nclose this gap is to automatically obtain type checkers from declarative<br>\nprogramming language specifications.&nbsp; This moves the burden of proving<br>\ncorrectness from a case-by-case basis for concrete languages, to a single<br>\ncorrectness proof for the specification language.</p>\n\n<p>This vision is obstructed by an aspect common to all programming languages: name<br>\nresolution.&nbsp; Naming and scoping are pervasive and complex aspects of the static<br>\nsemantics of programming languages.&nbsp; Implementations of type checkers for<br>\nlanguages with name binding features such as modules, imports, classes, and<br>\ninheritance interleave collection of binding information (i.e., declarations,<br>\nscoping structure, and imports) and querying that information.&nbsp; This requires<br>\nscheduling those two aspects in such a way that query answers are stable---i.e.,<br>\nthey are computed only after all relevant binding structure has been collected.<br>\nType checkers for concrete languages accomplish stability using<br>\nlanguage-specific knowledge about the type system.</p>\n\n<p>In this paper we give a language-independent characterization of necessary and<br>\nsufficient conditions to guarantee stability of name and type queries during<br>\ntype checking in terms of _critical edges in an incomplete scope graph_.<br>\nWe use critical edges to give a formal small-step operational semantics to a<br>\ndeclarative specification language for type systems, that achieves soundness by<br>\ndelaying queries that may depend on missing information.&nbsp; This yields type<br>\ncheckers for the specified languages that are sound by construction---i.e., they<br>\nschedule queries so that the answers are stable, and only accept programs that<br>\nare name- and type-correct according to the declarative language specification.<br>\nWe implement this approach, and evaluate it against specifications of a small<br>\nmodule and record language, as well as subsets of Java and Scala.</p>\n\n<p>&nbsp;</p>", 
  "author": [
    {
      "family": "Arjen Rouvoet"
    }, 
    {
      "family": "Hendrik van Antwerpen"
    }, 
    {
      "family": "Casper Bach Poulsen"
    }, 
    {
      "family": "Robbert Krebbers"
    }, 
    {
      "family": "Eelco Visser"
    }
  ], 
  "version": "1.0", 
  "type": "article", 
  "id": "4068065"
}
62
1
views
downloads
All versions This version
Views 6262
Downloads 11
Data volume 1.5 GB1.5 GB
Unique views 5252
Unique downloads 11

Share

Cite as