polsevev/master
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Added one more section to future work

Browse source
This commit is contained in:
Rolf Martin Glomsrud 2024-05-30 21:03:12 +02:00
parent 358550c89a
commit d3ad06523d
2 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

BIN
build/report.pdf
View file

Binary file not shown.

2
chapter/future_work.tex
View file

@ -18,4 +18,4 @@ In this thesis, we have developed a way to define transformations of JavaScript
\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 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{} \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.