34 lines
2.9 KiB
TeX
34 lines
2.9 KiB
TeX
\chapter{Conclusion and Future Work}
|
|
|
|
In this thesis,
|
|
we have explored an approach to define transformations of JavaScript code
|
|
based on formal specifications of syntactic proposals.
|
|
The goal of such transformations is to gather (early) feedback for (contentious) syntactic ECMAScript language proposals discussed by the TC39 committee.
|
|
Our tool opens a possibility for the users to ``preview''
|
|
proposals on their own codebases:
|
|
it can be conjectured that users' familiarity with the code
|
|
shall improve the quality of feedback.
|
|
|
|
The work presented in this thesis is an initial step in developing a language workbench-like tool for supporting design of widely adopted programming languages. While this thesis adequately implements the machinery of the core of such a tool, future work is required.
|
|
A major next step is to \textbf{integrate a feedback gathering mechanism in an IDE}. This shall give users a way to apply proposals to fragments of their code \emph{and} to be able to give feedback on every such application. This could be implemented, for example, using a rating scale (e.g., Likert scale) to quantify
|
|
user's preferences. The user would also be able to submit their code (in an obfuscated form) directly to the TC39 committee.
|
|
|
|
We have also identified several directions on how the
|
|
\textbf{expressiveness of \DSL{} can be improved.}
|
|
For example, \emph{parameterized specifications}
|
|
can be introduced to enable reuse of (parts of) proposal specifications.
|
|
Another example is to \emph{support a richer syntax for wildcards}---this would allow for more power matching and transformations of the AST structures.
|
|
Currently, our tool relies heavily on abstract syntax trees produced by Babel.
|
|
While this can be considered as an advantage for the TC39's use case,
|
|
introducing \textbf{support for arbitrary JavaScript parsers} can be beneficial.
|
|
|
|
%Introducing some way of defining new syntax for a proposal in the proposal definition, and allowing for parsing JavaScript containing that specific new syntax would limit the reliance on Babel, and allow for defining proposals earlier in the development process. This can possibly be done by implementing a custom parser inside this tool that allows defining custom syntax for specific new proposals.
|
|
|
|
%\emph{Fully self-hosting \DSL{}SH} The current version of \DSL{}SH relies on this tools parser to generate the AST for the type expressions used for matching by wildcards. This might make this tool more difficult to adopt for the committee. Therefore adding functionality for writing these type expressions purely in JavaScript and allowing for the use of JavaScript as its own meta language is an interesting avenue to explore.
|
|
|
|
|
|
Ultimately, \textbf{supporting other programming languages} in our tool could help in performing corpus analysis when designing new features for both ECMAScript and those other languages. In addition, this could enable exploring \emph{co-evolution} of programming languages.
|
|
|
|
|
|
|
|
|