Software Open Access

Knowing When to Ask: Artifact

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


MARC21 XML Export

<?xml version='1.0' encoding='UTF-8'?>
<record xmlns="http://www.loc.gov/MARC21/slim">
  <leader>00000nmm##2200000uu#4500</leader>
  <datafield tag="653" ind1=" " ind2=" ">
    <subfield code="a">Statix</subfield>
  </datafield>
  <datafield tag="653" ind1=" " ind2=" ">
    <subfield code="a">Haskell</subfield>
  </datafield>
  <controlfield tag="005">20201008002701.0</controlfield>
  <controlfield tag="001">4068065</controlfield>
  <datafield tag="700" ind1=" " ind2=" ">
    <subfield code="u">Delft University of Technology</subfield>
    <subfield code="a">Hendrik van Antwerpen</subfield>
  </datafield>
  <datafield tag="700" ind1=" " ind2=" ">
    <subfield code="u">Delft University of Technology</subfield>
    <subfield code="a">Casper Bach Poulsen</subfield>
  </datafield>
  <datafield tag="700" ind1=" " ind2=" ">
    <subfield code="u">Delft University of Technology</subfield>
    <subfield code="a">Robbert Krebbers</subfield>
  </datafield>
  <datafield tag="700" ind1=" " ind2=" ">
    <subfield code="u">Delft University of Technology</subfield>
    <subfield code="a">Eelco Visser</subfield>
  </datafield>
  <datafield tag="856" ind1="4" ind2=" ">
    <subfield code="s">1463910395</subfield>
    <subfield code="z">md5:1cc756023d96232b65fd52956e2f2c5f</subfield>
    <subfield code="u">https://zenodo.org/record/4068065/files/knowing-when-to-ask.tar.gz</subfield>
  </datafield>
  <datafield tag="542" ind1=" " ind2=" ">
    <subfield code="l">open</subfield>
  </datafield>
  <datafield tag="260" ind1=" " ind2=" ">
    <subfield code="c">2020-10-06</subfield>
  </datafield>
  <datafield tag="909" ind1="C" ind2="O">
    <subfield code="p">software</subfield>
    <subfield code="o">oai:zenodo.org:4068065</subfield>
  </datafield>
  <datafield tag="100" ind1=" " ind2=" ">
    <subfield code="u">Delft University of Technology</subfield>
    <subfield code="a">Arjen Rouvoet</subfield>
  </datafield>
  <datafield tag="245" ind1=" " ind2=" ">
    <subfield code="a">Knowing When to Ask: Artifact</subfield>
  </datafield>
  <datafield tag="540" ind1=" " ind2=" ">
    <subfield code="u">https://opensource.org/licenses/Apache-2.0</subfield>
    <subfield code="a">Apache License 2.0</subfield>
  </datafield>
  <datafield tag="650" ind1="1" ind2="7">
    <subfield code="a">cc-by</subfield>
    <subfield code="2">opendefinition.org</subfield>
  </datafield>
  <datafield tag="520" ind1=" " ind2=" ">
    <subfield code="a">&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;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;</subfield>
  </datafield>
  <datafield tag="773" ind1=" " ind2=" ">
    <subfield code="n">doi</subfield>
    <subfield code="i">isVersionOf</subfield>
    <subfield code="a">10.5281/zenodo.4068064</subfield>
  </datafield>
  <datafield tag="024" ind1=" " ind2=" ">
    <subfield code="a">10.5281/zenodo.4068065</subfield>
    <subfield code="2">doi</subfield>
  </datafield>
  <datafield tag="980" ind1=" " ind2=" ">
    <subfield code="a">software</subfield>
  </datafield>
</record>
61
1
views
downloads
All versions This version
Views 6161
Downloads 11
Data volume 1.5 GB1.5 GB
Unique views 5151
Unique downloads 11

Share

Cite as