19 lines
3.6 KiB
TeX
19 lines
3.6 KiB
TeX
\chapter{Conclusions \& Future Work}
|
|
|
|
\section{Conclusions}
|
|
|
|
In this thesis, we have developed a way to define transformations of JavaScript based on a proposal definition. The idea this thesis started to explore is to create a way to gather early feedback on syntactic proposals for ECMAScript. The tool created allows for matching and transformation of user code based on a proposal definition. This is the initial step of gathering user feedback by using a user's familiarity with their own code. While more work still remains, this thesis has proved the idea of transforming user code to use new proposals to be feasible.
|
|
|
|
\section{Future Work}
|
|
|
|
\textbf{Provide access and gather feedback} This project is build upon creating a tool for users of EcmaScript to see new proposals within their own codebase. The idea behind this is to use the users familiarity to showcase new syntactic proposals, and get valuable feedback to the committee developing the ECMA-262 standard. This means making the definitions of a proposal in \DSL and this tool available to end-users to execute using their own code. This can come in multiple forms, we suggest some ideas, such as a playground on the web, an extension for Visual Studio Code, or to be used in github pull requests.
|
|
|
|
\textbf{Supporting other languages} The idea of showcasing changes to a programming language by transforming user code is not only limited to EcmaScript, and could be applied to many other programming languages using a similar development method to EcmaScript. The developers of a language could write definitions of new changes for their respective language, and use a similar tool to the one discussed in this thesis to showcase possible new changes.
|
|
|
|
\textbf{Parameterized specifications} The current form of \DSL supports writing each template as its own respective case, but multiple templates might be very similar and could be written using generics that are shared between case definitions. Introducing this might give a simpler way of writing more complex definitions of a proposal transformation by re-using generic type parameters for the wildcards used in the transformations.
|
|
|
|
\textbf{Fully self-hosting \DSLSH} The current version of \DSLSH 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.
|
|
|
|
\textbf{Support for custom proposal syntax} Currently this tool relies heavily on that a proposal is supported by Babel~\cite{Babel}. This makes the tool quite limited in what proposals could be defined and transformed due to relying on Babel for parsing the templates and generating the output code. 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.
|
|
|
|
\textbf{Support of a wider syntax for wildcards} The current syntax for wildcards allow limiting on node types only. An interesting avenue of exploration is to specify wildcards with code snippets in them. This would allow for an even deeper template structure to define matches, and would also give the transformation a more specified expected structure to insert.
|