Software Open Access

Knowing When to Ask: Artifact

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


Dublin Core Export

<?xml version='1.0' encoding='utf-8'?>
<oai_dc:dc xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd">
  <dc:creator>Arjen Rouvoet</dc:creator>
  <dc:creator>Hendrik van Antwerpen</dc:creator>
  <dc:creator>Casper Bach Poulsen</dc:creator>
  <dc:creator>Robbert Krebbers</dc:creator>
  <dc:creator>Eelco Visser</dc:creator>
  <dc:date>2020-10-06</dc:date>
  <dc:description>There is a large gap between the specification of type systems and the
implementation of their type checkers, which impedes reasoning about the
soundness of the type checker with respect to the specification.  A vision to
close this gap is to automatically obtain type checkers from declarative
programming language specifications.  This moves the burden of proving
correctness from a case-by-case basis for concrete languages, to a single
correctness proof for the specification language.

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

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

 </dc:description>
  <dc:identifier>https://zenodo.org/record/4068065</dc:identifier>
  <dc:identifier>10.5281/zenodo.4068065</dc:identifier>
  <dc:identifier>oai:zenodo.org:4068065</dc:identifier>
  <dc:relation>doi:10.5281/zenodo.4068064</dc:relation>
  <dc:rights>info:eu-repo/semantics/openAccess</dc:rights>
  <dc:rights>https://opensource.org/licenses/Apache-2.0</dc:rights>
  <dc:subject>Statix</dc:subject>
  <dc:subject>Haskell</dc:subject>
  <dc:title>Knowing When to Ask: Artifact</dc:title>
  <dc:type>info:eu-repo/semantics/other</dc:type>
  <dc:type>software</dc:type>
</oai_dc:dc>
64
1
views
downloads
All versions This version
Views 6464
Downloads 11
Data volume 1.5 GB1.5 GB
Unique views 5454
Unique downloads 11

Share

Cite as