8,988 research outputs found

    EVF: An Extensible and Expressive Visitor Framework for Programming Language Reuse (Artifact)

    Get PDF
    This artifact is based on EVF, an extensible and expressive Java visitor framework. EVF aims at reducing the effort involved in creation and reuse of programming languages. EVF an annotation processor that automatically generate boilerplate ASTs and AST for a given an Object Algebra interface. This artifact contains source code of the case study on "Types and Programming Languages", illustrating how effective EVF is in modularizing programming languages. There is also a microbenchmark in the artifact that shows that EVF has reasonable performance with respect to traditional visitors

    EVF: An Extensible and Expressive Visitor Framework for Programming Language Reuse

    Get PDF

    Dependent Merges and First-Class Environments

    Get PDF
    In most programming languages a (runtime) environment stores all the definitions that are available to programmers. Typically, environments are a meta-level notion, used only conceptually or internally in the implementation of programming languages. Only a few programming languages allow environments to be first-class values, which can be manipulated directly in programs. Although there is some research on calculi with first-class environments for statically typed programming languages, these calculi typically have significant restrictions. In this paper we propose a statically typed calculus, called ?_i, with first-class environments. The main novelty of the ?_i calculus is its support for first-class environments, together with an expressive set of operators that manipulate them. Such operators include: reification of the current environment, environment concatenation, environment restriction, and reflection mechanisms for running computations under a given environment. In ?_i any type can act as a context (i.e. an environment type) and contexts are simply types. Furthermore, because ?_i supports subtyping, there is a natural notion of context subtyping. There are two important ideas in ?_i that generalize and are inspired by existing notions in the literature. The ?_i calculus borrows disjoint intersection types and a merge operator, used in ?_i to model contexts and environments, from the ?_i calculus. However, unlike the merges in ?_i, the merges in ?_i can depend on previous components of a merge. From implicit calculi, the ?_i calculus borrows the notion of a query, which allows type-based lookups on environments. In particular, queries are key to the ability of ?_i to reify the current environment, or some parts of it. We prove the determinism and type soundness of ?_i, and show that ?_i can encode all well-typed ?_i programs

    Dependent Merges and First-Class Environments (Artifact)

    Get PDF
    This artifact contains the mechanical formalization of the calculi associated with the paper Dependent Merges and First-Class Environments. All of the metatheory has been formalized in Coq theorem prover. The paper studies a statically typed calculus, called ?_i, with first-class environments. The main novelty of the ?_i calculus is its support for first-class environments, together with an expressive set of operators that manipulate them

    A Type-Directed Operational Semantics For a Calculus with a Merge Operator

    Get PDF

    Type-Directed Operational Semantics for Gradual Typing (Artifact)

    Get PDF
    This artifact includes the Coq formalization associated with the paper Type-Directed Operational Semantics for Gradual Typing submitted in ECOOP 2021. The paper illustrates how to employ TDOS on gradually typed languages using two calculi. The first calculus, called ?B, is inspired by the semantics of the blame calculus(?B^g) and is sound with ?B^g. The second calculus, called ?B^r, explores a different design space in the semantics of gradually typed languages. This document explains how to run the Coq formalization. Artifact can either be compiled in the pre-built docker image with all the dependencies installed or it could be built from the scratch. Sections 1-7 explain the basic information about the artifact. Section 7 explains how to get the docker image for the artifact. Section 8 explains the prerequisites and the steps to run coq files from scratch. Section 9 explains coq files briefly. Section 10 shows the correspondence of important lemmas, definitions and pictures discussed in the paper with their respective Coq formalization
    • …
    corecore