A constraint language for static semantic analysis based on scope graphs

Antwerpen, Hendrik van; Neron, Pierre; Tolmach, Andrew; Visser, Eelco; Wachsmuth, Guido

doi:10.1145/2847538.2847543

Cited by 39 publications

(32 citation statements)

References 19 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…This avoids duplication of scope graphs, and makes the approach promising for languages that do normalization during type checking for types with rich binding structure. It also shows that scope graphs and the revised resolution calculus presented in Section 2.1 provide a theory for name binding and name resolution in type systems that scales to languages beyond the relatively simple type systems that scope graphs were demonstrated to work previously [Néron et al 2015;Poulsen et al 2016Poulsen et al , 2018van Antwerpen et al 2016].…”

Section: Discussionmentioning

confidence: 87%

“…Label well-formedness tests that the path has a 'good shape' as defined by a regular label well-formedness WFL ⊆ L * defined as a regular expression data order expression. This is used to model policies such as transitive vs. non-transitive imports or the unreachability of lexical parents of imported modules [Van Antwerpen et al 2016]. Data term well-formedness tests whether we have found the datum we were looking for.…”

Section: Scope Graphs and The Resolution Calculusmentioning

confidence: 99%

“…This means that new types can be created 'on the fly', that is, not all types have to be defined by name. In previous work, Van Antwerpen et al [2016] show how to represent nominal record types with scope graphs, but not how to express structural comparisons and composition of such types. Here we show how to do that using scopes as types and scope graph queries.…”

Section: Records and Structural Subtypingmentioning

confidence: 99%

See 2 more Smart Citations

Scopes as types

Antwerpen

Poulsen

Rouvoet

et al. 2018

Proc. ACM Program. Lang.

Self Cite

View full text Add to dashboard Cite

Scope graphs are a promising generic framework to model the binding structures of programming languages, bridging formalization and implementation, supporting the definition of type checkers and the automation of type safety proofs. However, previous work on scope graphs has been limited to simple, nominal type systems. In this paper, we show that viewing scopes as types enables us to model the internal structure of types in a range of non-simple type systems (including structural records and generic classes) using the generic representation of scopes. Further, we show that relations between such types can be expressed in terms of generalized scope graph queries. We extend scope graphs with scoped relations and queries. We introduce Statix, a new domain-specific metalanguage for the specification of static semantics, based on scope graphs and constraints. We evaluate the scopes as types approach and the Statix design in case studies of the simply-typed lambda calculus with records, System F, and Featherweight Generic Java.

show abstract

Section: Discussionmentioning

confidence: 87%

Section: Scope Graphs and The Resolution Calculusmentioning

confidence: 99%

Section: Records and Structural Subtypingmentioning

confidence: 99%

See 1 more Smart Citation

Scopes as types

Antwerpen

Poulsen

Rouvoet

et al. 2018

Proc. ACM Program. Lang.

Self Cite

View full text Add to dashboard Cite

show abstract

“…As the basis for our investigations we use Statix, a constraint language developed for the specification of type systems [21]. Statix is built around scope graphs, a language-independent model for name binding and name resolution [20]. We argue that Statix is a suitable basis for the definition of editor services by expressing them in terms of Statix constraints and Statix type system specifications.…”

Section: Towards Language-parametric Semantic Editor Services Based Omentioning

confidence: 99%

Towards language-parametric semantic editor services based on declarative type system specifications

Pelsmaeker

Antwerpen

Visser

2019

Proceedings Companion of the 2019 ACM SIGPLAN International Conference on Systems, Programming, Languages, and Applications: So

Self Cite

View full text Add to dashboard Cite

Editor services assist programmers to more effectively write and comprehend code. Implementing editor services correctly is not trivial. This paper focuses on the specification of semantic editor services, those that use the semantic model of a program. The specification of refactorings is a common subject of study, but many other semantic editor services have received little attention. We propose a language-parametric approach to the definition of semantic editor services, using a declarative specification of the static semantics of the programming language, and constraint solving. Editor services are specified as constraint problems, and language specifications are used to ensure correctness. We describe our approach for the following semantic editor services: reference resolution, find usages, goto subclasses, code completion, and the extract definition refactoring. We do this in the context of Statix, a constraint language for the specification of type systems. We investigate the specification of editor services in terms of Statix constraints, and the requirements these impose on a suitable solver.

show abstract

“…In the Spoofax ecosystem, a programming language is specified in terms of multiple high-level declarative meta-language definitions, where each meta-language covers a language-independent aspect (e.g., separate syntax definition [45], name binding rules [3,29,35], or the dynamic semantics definition of a programming language [43]). Subsequently, Spoofax generates a complete implementation of a programming language, given all the meta-language definitions.…”

Section: Case Study: Spoofax Language Workbenchmentioning

confidence: 99%

PIE: A Domain-Specific Language for Interactive Software Development Pipelines

et al. 2018

Self Cite

View full text Add to dashboard Cite

Context. Software development pipelines are used for automating essential parts of software engineering processes, such as build automation and continuous integration testing. In particular, interactive pipelines, which process events in a live environment such as an IDE, require timely results for low-latency feedback, and persistence to retain low-latency feedback between restarts. Inquiry. Developing an incrementalized and persistent version of a pipeline is one way to reduce feedback latency, but requires implementation of dependency tracking, cache invalidation, and other complicated and error-prone techniques. Therefore, interactivity complicates pipeline development if timeliness and persistence become responsibilities of the pipeline programmer, rather than being supported by the underlying system. Systems for programming incremental and persistent pipelines exist, but do not focus on ease of development, requiring a high degree of boilerplate, increasing development and maintenance effort. Approach. We develop Pipelines for Interactive Environments (PIE), a Domain-Specific Language (DSL), API, and runtime for developing interactive software development pipelines, where ease of development is a focus. The PIE DSL is a statically typed and lexically scoped language. PIE programs are compiled to programs implementing the API, which the PIE runtime executes in an incremental and persistent way. Knowledge. PIE provides a straightforward programming model that enables direct and concise expression of pipelines without boilerplate, reducing the development and maintenance effort of pipelines. Compiled pipeline programs can be embedded into interactive environments such as code editors and IDEs, enabling timely feedback at a low cost. Grounding. Compared to the state of the art, PIE reduces the code required to express an interactive pipeline by a factor of 6 in a case study on syntax-aware editors. Furthermore, we evaluate PIE in two case studies of complex interactive software development scenarios, demonstrating that PIE can handle complex interactive pipelines in a straightforward and concise way. Importance. Interactive pipelines are complicated software artifacts that power many important systems such as continuous feedback cycles in IDEs and code editors, and live language development in language workbenches. New pipelines, and evolution of existing pipelines, is frequently necessary. Therefore, a system for easily developing and maintaining interactive pipelines, such as PIE, is important. ACM CCS 2012 Software and its engineering → Domain specific languages; Development frameworks and environments; Source code generation; Runtime environments;Keywords domain-specific language, pipeline, interactive software development, incremental

show abstract

A constraint language for static semantic analysis based on scope graphs

Cited by 39 publications

References 19 publications

Scopes as types

Scopes as types

Towards language-parametric semantic editor services based on declarative type system specifications

PIE: A Domain-Specific Language for Interactive Software Development Pipelines

Contact Info

Product

Resources

About