ch3 almost finito
This commit is contained in:
parent
ce31069119
commit
8593500aa1
3 changed files with 29 additions and 32 deletions
BIN
build/report.pdf
BIN
build/report.pdf
Binary file not shown.
|
|
@ -52,7 +52,7 @@ let c = 200;
|
|||
|
||||
See that in \ref{ex:proposal} the change is optional, and is not applied to the declaration of \textit{c}, but it is applied to the declaration of \textit{x}. Since the change is optional to use, and essentially is just \textit{syntax sugar}, this proposal does not make any changes to functionality or semantics, and can therefore be categorized as a syntactic proposal.
|
||||
|
||||
\subsection{Discard Bindings}
|
||||
\subsection{\cite[Discard Bindings]{Proposal:DiscardBindings}}
|
||||
|
||||
The proposal \discardBindings is classified as a Syntactic Proposal, as it contains no change to the semantics of EcmaScript. This proposal is created to allow for discarding objects when using the feature of unpacking objects/arrays on the left side of an assignment. The whole idea of this proposal is to avoid declaring unused temporary variables.
|
||||
|
||||
|
|
@ -278,20 +278,18 @@ var minLoc = grunt.config('uglify.all.files') |> Object.keys(%)[0];
|
|||
|
||||
\subsection{Do proposal}
|
||||
|
||||
This is where a description of the Do proposal might land
|
||||
|
||||
\subsection{Async to promises?}
|
||||
|
||||
Outline the rewriting of async to promises here
|
||||
This is where a description of the Do proposal might land even though actually defining the do proposal will be quite difficult, as it is hard to see exactly where one can apply this LOOOOL
|
||||
|
||||
|
||||
\subsection{Await to Promise}
|
||||
|
||||
This section contains a description of a use-case of this DSL for rewriting code using the \textit{await} keyword to use a Promise in stead.
|
||||
|
||||
\section{Searching user code for applicable snippets}
|
||||
|
||||
In order to identify snippets of code in the users codebase where a proposal is applicable we need some way to define patterns of code where we can apply the proposal. To do this, a DSL titled \DSL is used.
|
||||
|
||||
\section{\DSL}
|
||||
\subsection{\DSL}
|
||||
|
||||
In order to allow for the utilization of the users code. We have to identify snippets of the users code that some proposal is applicable to. In order to do this, we have designed a DSL called \DSL JavaScript Template Query Language. This DSL will contain the entire definition used to identify and transform user code in order to showcase a proposal.
|
||||
|
||||
|
|
@ -301,17 +299,23 @@ In order to identify snippets of code a proposal is applicable to, we use templa
|
|||
|
||||
A template containing none of these \textit{wildcards} is matched exactly. This essentially means the match will be a direct code search for snippets where the AST of the users code match the template exactly.
|
||||
|
||||
The \textit{wildcards} are written inside a block denoted by << WILDCARD >>. Each wildcard has to have an DSL identifier, a way of referring to that wildcard in the definition of the transformation.
|
||||
The \textit{wildcards} are written inside a block denoted by << WILDCARD >>. Each wildcard has to have a DSL identifier, a way of referring to that wildcard in the definition of the transformation.
|
||||
|
||||
Each wildcard has to have some form of type. These types can be node-types inherited from Babels AST definition. This means if you want a wildcard to match any \textit{CallExpression} then that wildcard should be of type CallExpression. In order to allow for multiple node-types to match against a single wildcard, \DSL allows for sum types for wildcards, allowing multiple AST node-types to be allowed to a single wildcard definition.
|
||||
|
||||
This type definition is also used to define specific behavior the program using this DSL should perform. One example of this can be found in \ref{def:pipeline}, where the DSL function \textit{anyRest} is used to allow for any amount of child nodes found together with the wildcard. This means it is feasible to match against any number of function parameters for example.
|
||||
|
||||
\begin{lstlisting}[caption={Example of a wildcard}, label={ex:wildcard}]
|
||||
let variableName = << expr1: CallExpression | Identifier >>;
|
||||
\end{lstlisting}
|
||||
|
||||
In \ref{ex:wildcard} a wildcard section is defined on the right hand side of an assignment statement. This wildcard will match against any AST node classified as a CallExpression or an Identifier. The DSL reuses the AST node-types from Babel.
|
||||
|
||||
In \ref{ex:wildcard} a wildcard section is defined on the right hand side of an assignment statement. This wildcard will match against any AST node classified as a CallExpression or an Identifier.
|
||||
|
||||
|
||||
\subsection{Transforming}
|
||||
|
||||
Observe that once the a matching template has been defined, a definition of transformation has to be created. This transformation has to transfer over the code matched to a wildcard. This means a way to refer to the wildcard is needed. We do this in a very similar manner as defining the wildcard, since we have an internal DSL identifier, all that is needed is to refer to that identifier. This is done with a similar block definition (<<>>) containing the identifier.
|
||||
Observe that once the a matching template has been defined, a definition of transformation has to be created. This transformation has to transfer over the code matched to a wildcard. This means a way to refer to the wildcard is needed. We do this in a very similar manner as defining the wildcard, since we have an internal DSL identifier previously defined in the definition of the matching, all that is needed is to refer to that identifier. This is done with a similar block definition << >> containing the identifier.
|
||||
|
||||
\begin{lstlisting}[caption={
|
||||
See \ref{ex:wildcard} contains identifier expr1, and we refer to the same in this example, the only transformation happening here is rewriting let to const.
|
||||
|
|
@ -320,6 +324,7 @@ const variableName = <<expr1>>;
|
|||
\end{lstlisting}
|
||||
|
||||
|
||||
|
||||
\subsection{Structure of \DSL}
|
||||
|
||||
\DSL is designed to mimic the examples already provided by a proposal champion in the proposals README. These examples can be seen in each of the proposals described in \ref{sec:proposals}.
|
||||
|
|
@ -387,12 +392,6 @@ proposal PROPOSAL_NAME {
|
|||
\end{lstlisting}
|
||||
|
||||
|
||||
|
||||
\section{\DSL}
|
||||
|
||||
|
||||
|
||||
|
||||
\section{Using the \DSL with an actual syntactic proposal}
|
||||
|
||||
|
||||
|
|
@ -401,7 +400,7 @@ proposal PROPOSAL_NAME {
|
|||
The Pipeline Proposal is the easiest to define of the proposals presented in \ref*{sec:proposals}. This is due to the proposal being applicable to a very wide array of expressions, and the main problem this proposal is trying to solve is deep nesting of function calls.
|
||||
|
||||
|
||||
\begin{lstlisting}[language={JavaScript}, caption={Example of Pipeline Proposal definition in \DSL}]
|
||||
\begin{lstlisting}[language={JavaScript}, caption={Example of Pipeline Proposal definition in \DSL}, label={def:pipeline}]
|
||||
proposal Pipeline{
|
||||
pair 1 {
|
||||
applicable to {
|
||||
|
|
@ -428,4 +427,6 @@ proposal Pipeline{
|
|||
}
|
||||
\end{lstlisting}
|
||||
|
||||
This first pair definition of the Pipeline proposal will apply to any \textit{CallExpression} with a single parameter. And it will be applied to each of the deeply nested callExpressions.
|
||||
This first pair definition of the Pipeline proposal will apply to any \textit{CallExpression} with a single parameter. And it will be applied to each of the deeply nested callExpressions.
|
||||
|
||||
As can be seen in \ref{def:pipeline}
|
||||
|
|
@ -1,14 +1,10 @@
|
|||
@inproceedings{raftAlg,
|
||||
author = {Ongaro, Diego and Ousterhout, John},
|
||||
title = {In Search of an Understandable Consensus Algorithm},
|
||||
booktitle = {Proceedings of the 2014 USENIX Conference on USENIX Annual Technical Conference},
|
||||
series = {USENIX ATC'14},
|
||||
year = {2014},
|
||||
isbn = {978-1-931971-10-2},
|
||||
location = {Philadelphia, PA},
|
||||
pages = {305--320},
|
||||
numpages = {16},
|
||||
acmid = {2643666},
|
||||
publisher = {USENIX Association},
|
||||
address = {Berkeley, CA, USA},
|
||||
}
|
||||
|
||||
|
||||
@misc{Proposal:DiscardBindings,
|
||||
title = {{proposal-discard-binding}},
|
||||
journal = {GitHub},
|
||||
year = {2024},
|
||||
month = apr,
|
||||
note = {[Online; accessed 25. Apr. 2024]},
|
||||
url = {https://github.com/tc39/proposal-discard-binding?tab=readme-ov-file#object-binding-and-assignment-patterns}
|
||||
}
|
||||
Loading…
Reference in a new issue