E. Visser
Please Note
21 records found
1
Dynamix specifications compile source programs to the Tim intermediate representation, a language-agnostic target IR designed to be able to be efficiently interpreted or compiled. Dynamix and Tim make use of the continuation-passing style to abstract over control flow, giving language developers fine-grained access to control flow primitives in their specification. A novel abstraction in Dynamix allows the construction of these CPS terms without the traditional friction involved. Dynamix is fully typed and integrated within the Spoofax language workbench. This allows language developers to interact directly with other parts of the workbench, including automatic type signature generation and the ability to query the results of static analysis.
Through case studies for miniStratego and ChocoPy with exceptions, we show that Dynamix is capable of succinctly representing a wide range of source language features and paradigms. Current performance is acceptable, with the foundations for a future efficient compiler for the Tim IR already in place. ...
Dynamix specifications compile source programs to the Tim intermediate representation, a language-agnostic target IR designed to be able to be efficiently interpreted or compiled. Dynamix and Tim make use of the continuation-passing style to abstract over control flow, giving language developers fine-grained access to control flow primitives in their specification. A novel abstraction in Dynamix allows the construction of these CPS terms without the traditional friction involved. Dynamix is fully typed and integrated within the Spoofax language workbench. This allows language developers to interact directly with other parts of the workbench, including automatic type signature generation and the ability to query the results of static analysis.
Through case studies for miniStratego and ChocoPy with exceptions, we show that Dynamix is capable of succinctly representing a wide range of source language features and paradigms. Current performance is acceptable, with the foundations for a future efficient compiler for the Tim IR already in place.
This requires precise definitions of the dependencies for build steps.
PIE is a build system with precise dependencies, but its task definitions in Java are verbose.
The PIE DSL allows pipeline developers to write concise definitions of PIE tasks, but the PIE framework has evolved and the PIE DSL cannot express many tasks and projects.
This thesis presents PIE DSL 2, which improves on PIE DSL 1 in three areas.
It extends the language itself with a module system, generics and support for suppliers and injected values, which allows it to express more tasks within the DSL.
There are four improvements for the code base.
The first two are a specification of the static semantics in Statix and a new compiler backend that compiles to an AST instead of using string interpolation, both of which extend the features for the DSL that can be expressed.
The second pair is constructors for semantic types and tests, which improve development speed of the DSL.
The final area we improve is the user experience, which we improve by adding documentation for expressions and types in the PIE DSL.
We compare PIE DSL 2 to Java in a case study.
Only a single task can be expressed in the DSL, which means that the boilerplate is not reduced.
Furthermore, the Java ecosystem has better error detection except for nullability.
Finally, the PIE DSL is simpler than Java, but only when the full pipeline is supported by the DSL.
We conclude that the DSL is not better than Java for full projects yet, but for tasks that it can express it is a slight improvement over Java.
This leads to the hypothesis that it has potential to become better if it can express enough tasks.
Due to time constraints, the case study did not use the latest version of the DSL.
In theory the latest version of the DSL can express 11 of the 19 tasks, but this has not been verified experimentally.
Overall, this thesis makes improvements to the PIE DSL and its environment, but that has not translated to the DSL being better than Java. ...
This requires precise definitions of the dependencies for build steps.
PIE is a build system with precise dependencies, but its task definitions in Java are verbose.
The PIE DSL allows pipeline developers to write concise definitions of PIE tasks, but the PIE framework has evolved and the PIE DSL cannot express many tasks and projects.
This thesis presents PIE DSL 2, which improves on PIE DSL 1 in three areas.
It extends the language itself with a module system, generics and support for suppliers and injected values, which allows it to express more tasks within the DSL.
There are four improvements for the code base.
The first two are a specification of the static semantics in Statix and a new compiler backend that compiles to an AST instead of using string interpolation, both of which extend the features for the DSL that can be expressed.
The second pair is constructors for semantic types and tests, which improve development speed of the DSL.
The final area we improve is the user experience, which we improve by adding documentation for expressions and types in the PIE DSL.
We compare PIE DSL 2 to Java in a case study.
Only a single task can be expressed in the DSL, which means that the boilerplate is not reduced.
Furthermore, the Java ecosystem has better error detection except for nullability.
Finally, the PIE DSL is simpler than Java, but only when the full pipeline is supported by the DSL.
We conclude that the DSL is not better than Java for full projects yet, but for tasks that it can express it is a slight improvement over Java.
This leads to the hypothesis that it has potential to become better if it can express enough tasks.
Due to time constraints, the case study did not use the latest version of the DSL.
In theory the latest version of the DSL can express 11 of the 19 tasks, but this has not been verified experimentally.
Overall, this thesis makes improvements to the PIE DSL and its environment, but that has not translated to the DSL being better than Java.
Navigating Through Digital Printing Systems
The Use of a Domain-Specific Language for Route Finding in Digital Printing Systems
...
Renaming for Everyone
Language-parametric Renaming in Spoofax
Verifying the Semantics of Disambiguation Rules
Using Parse Tree Repairing for Showing Safety and Completeness of Associativity and Priority Rules
Framing Programming Languages
Designing and Using a Frame-Based Virtual Machine
...
Dynamix on the Frame VM
Declarative dynamic semantics on a VM using scopes as frames
As Spoofax was redesigned to become more robust and platform independent, the previous SPT is no longer compatible. We took this opportunity to redesign SPT. In this thesis we will discuss the benefits of a testing approach like SPT, how far along it is on the path of testing any language, and what is required to make it usable by modern day developers. We will analyze the problems that SPT had to tackle, how it solved them, and which problems still remain.
Finally, we present and evaluate our new design and implementation to solve some of these remaining problems. We created a platform independent, real-time performant, easily extendable architecture that allows SPT to be used for automated tasks such as continuous integration and the automated grading of students' domain specific languages. ...
As Spoofax was redesigned to become more robust and platform independent, the previous SPT is no longer compatible. We took this opportunity to redesign SPT. In this thesis we will discuss the benefits of a testing approach like SPT, how far along it is on the path of testing any language, and what is required to make it usable by modern day developers. We will analyze the problems that SPT had to tackle, how it solved them, and which problems still remain.
Finally, we present and evaluate our new design and implementation to solve some of these remaining problems. We created a platform independent, real-time performant, easily extendable architecture that allows SPT to be used for automated tasks such as continuous integration and the automated grading of students' domain specific languages.
Incrementalizing Statix
A Modular and Incremental Approach for Type Checking and Name Binding using Scope Graphs
SCL-T
Template programming for Siemens SCL
This work presents the first step towards language workbenches in Web IDEs by creating a language parametric runtime for the browser which serves as a back-end for Spoofax. Combined with an editor, this runtime is the basis for the generation of entirely client-side language playgrounds based on Spoofax specifications. For parsing, this runtime has similar performance characteristics as the existing Spoofax implementation. Code execution in this runtime can be used in environments where performance is not critical. ...
This work presents the first step towards language workbenches in Web IDEs by creating a language parametric runtime for the browser which serves as a back-end for Spoofax. Combined with an editor, this runtime is the basis for the generation of entirely client-side language playgrounds based on Spoofax specifications. For parsing, this runtime has similar performance characteristics as the existing Spoofax implementation. Code execution in this runtime can be used in environments where performance is not critical.
Language definitions made in the Spoofax language workbench can automatically expose their editor services in any editor that Spoofax supports. Therefore, we evaluate the portability of Spoofax Core, the editor-agnostic core of Spoofax, through an implementation of the workbench in the IntelliJ editor.
To get portability for editor services of languages in general, we first investigate how editor services can be added to the most popular editors, and explore their features, documentation, and API. From this, we derive a platform-agnostic model for portable editor services: AESI, the Adaptable Editor Services Interface. AESI describes the maximum set of common editor service features supported by the editors we investigated, while at the same time imposing minimal requirements upon any implementation of these editor services. We evaluate AESI by providing two language implementations, and adapting AESI to Eclipse, IntelliJ, and VS Code. Finally, we compare AESI with two other solutions to the IDE portability problem: LSP and Monto. ...
Language definitions made in the Spoofax language workbench can automatically expose their editor services in any editor that Spoofax supports. Therefore, we evaluate the portability of Spoofax Core, the editor-agnostic core of Spoofax, through an implementation of the workbench in the IntelliJ editor.
To get portability for editor services of languages in general, we first investigate how editor services can be added to the most popular editors, and explore their features, documentation, and API. From this, we derive a platform-agnostic model for portable editor services: AESI, the Adaptable Editor Services Interface. AESI describes the maximum set of common editor service features supported by the editors we investigated, while at the same time imposing minimal requirements upon any implementation of these editor services. We evaluate AESI by providing two language implementations, and adapting AESI to Eclipse, IntelliJ, and VS Code. Finally, we compare AESI with two other solutions to the IDE portability problem: LSP and Monto.