Software Open Access

Knowing When to Ask: Artifact

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

DataCite XML Export

<?xml version='1.0' encoding='utf-8'?>
<resource xmlns:xsi="" xmlns="" xsi:schemaLocation="">
  <identifier identifierType="DOI">10.5281/zenodo.4068065</identifier>
      <creatorName>Arjen Rouvoet</creatorName>
      <affiliation>Delft University of Technology</affiliation>
      <creatorName>Hendrik van Antwerpen</creatorName>
      <affiliation>Delft University of Technology</affiliation>
      <creatorName>Casper Bach Poulsen</creatorName>
      <affiliation>Delft University of Technology</affiliation>
      <creatorName>Robbert Krebbers</creatorName>
      <affiliation>Delft University of Technology</affiliation>
      <creatorName>Eelco Visser</creatorName>
      <affiliation>Delft University of Technology</affiliation>
    <title>Knowing When to Ask: Artifact</title>
    <date dateType="Issued">2020-10-06</date>
  <resourceType resourceTypeGeneral="Software"/>
    <alternateIdentifier alternateIdentifierType="url"></alternateIdentifier>
    <relatedIdentifier relatedIdentifierType="DOI" relationType="IsVersionOf">10.5281/zenodo.4068064</relatedIdentifier>
    <rights rightsURI="">Apache License 2.0</rights>
    <rights rightsURI="info:eu-repo/semantics/openAccess">Open Access</rights>
    <description descriptionType="Abstract">&lt;p&gt;There is a large gap between the specification of type systems and the&lt;br&gt;
implementation of their type checkers, which impedes reasoning about the&lt;br&gt;
soundness of the type checker with respect to the specification.&amp;nbsp; A vision to&lt;br&gt;
close this gap is to automatically obtain type checkers from declarative&lt;br&gt;
programming language specifications.&amp;nbsp; This moves the burden of proving&lt;br&gt;
correctness from a case-by-case basis for concrete languages, to a single&lt;br&gt;
correctness proof for the specification language.&lt;/p&gt;

&lt;p&gt;This vision is obstructed by an aspect common to all programming languages: name&lt;br&gt;
resolution.&amp;nbsp; Naming and scoping are pervasive and complex aspects of the static&lt;br&gt;
semantics of programming languages.&amp;nbsp; Implementations of type checkers for&lt;br&gt;
languages with name binding features such as modules, imports, classes, and&lt;br&gt;
inheritance interleave collection of binding information (i.e., declarations,&lt;br&gt;
scoping structure, and imports) and querying that information.&amp;nbsp; This requires&lt;br&gt;
scheduling those two aspects in such a way that query answers are stable---i.e.,&lt;br&gt;
they are computed only after all relevant binding structure has been collected.&lt;br&gt;
Type checkers for concrete languages accomplish stability using&lt;br&gt;
language-specific knowledge about the type system.&lt;/p&gt;

&lt;p&gt;In this paper we give a language-independent characterization of necessary and&lt;br&gt;
sufficient conditions to guarantee stability of name and type queries during&lt;br&gt;
type checking in terms of _critical edges in an incomplete scope graph_.&lt;br&gt;
We use critical edges to give a formal small-step operational semantics to a&lt;br&gt;
declarative specification language for type systems, that achieves soundness by&lt;br&gt;
delaying queries that may depend on missing information.&amp;nbsp; This yields type&lt;br&gt;
checkers for the specified languages that are sound by construction---i.e., they&lt;br&gt;
schedule queries so that the answers are stable, and only accept programs that&lt;br&gt;
are name- and type-correct according to the declarative language specification.&lt;br&gt;
We implement this approach, and evaluate it against specifications of a small&lt;br&gt;
module and record language, as well as subsets of Java and Scala.&lt;/p&gt;

All versions This version
Views 6161
Downloads 11
Data volume 1.5 GB1.5 GB
Unique views 5151
Unique downloads 11


Cite as