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

Cleaned up names of proposals

Browse source
This commit is contained in:
Rolf Martin Glomsrud 2024-06-01 12:25:13 +02:00
parent 6f2b9ff79b
commit 57522c21a4
3 changed files with 13 additions and 13 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.

24
chapter/ch3.tex
View file

@ -218,7 +218,7 @@ f1().f2(v1, v2).f3(v2).f4();
\end{minipage}\hfil
The ``Pipeline" proposal aims to combine the benefits of these two styles without the challenges each method faces. The proposal wants to achieve a similar style to chaining when doing deeply nested calls. The idea is to use syntactic sugar to change the writing order of the calls without influencing the API of the functions. Doing so will allow each call to come in the direction of left to right, while still maintaining the modularity of deeply nested function calls.
The ``Pipeline'' proposal aims to combine the benefits of these two styles without the challenges each method faces. The proposal wants to achieve a similar style to chaining when doing deeply nested calls. The idea is to use syntactic sugar to change the writing order of the calls without influencing the API of the functions. Doing so will allow each call to come in the direction of left to right, while still maintaining the modularity of deeply nested function calls.
The proposal introduces a \emph{pipe operator}, which takes the result of an expression on the left, and pipes it into an expression on the right. The location of where the result is piped to is where the topic token is located. All the specifics of the exact token used as a topic token and exactly what operator will be used as the pipe operator might be subject to change, and is currently under discussion~\cite{PipelineBikeshedding}.
@ -279,13 +279,13 @@ The pipe operator is present in many other languages such as F\#~\cite{FPipeOper
\subsection{``Do Expression'' Proposal}
The ``Do Expression''~\cite{Proposal:DoProposal} proposal is a proposal meant to bring a style of \textit{expression oriented programming}~\cite{ExpressionOriented} to ECMAScript. Expression oriented programming is a concept taken from functional programming which allows for combining expressions in a very free manner, resulting in a highly malleable programming experience.
The ``Do expression''~\cite{Proposal:DoProposal} proposal is a proposal meant to bring a style of \textit{expression oriented programming}~\cite{ExpressionOriented} to ECMAScript. Expression oriented programming is a concept taken from functional programming which allows for combining expressions in a very free manner, resulting in a highly malleable programming experience.
The motivation of the ``Do Expression'' proposal is to allow for local scoping of a code block that is treated as an expression. Thus, complex code requiring multiple statements will be confined inside its own scope~\cite[Sect. 8.2]{ecma262} and the resulting value is returned from the block implicitly as an expression, similarly to how unnamed functions or arrow functions are currently used. To achieve this behavior in the current version of ECMAScript, one needs to use immediately invoked; unnamed functions~\cite[Sect. 15.2]{ecma262} or arrow function~\cite[Sect. 15.3]{ecma262}.
The motivation of the ``Do expression'' proposal is to allow for local scoping of a code block that is treated as an expression. Thus, complex code requiring multiple statements will be confined inside its own scope~\cite[Sect. 8.2]{ecma262} and the resulting value is returned from the block implicitly as an expression, similarly to how unnamed functions or arrow functions are currently used. To achieve this behavior in the current version of ECMAScript, one needs to use immediately invoked; unnamed functions~\cite[Sect. 15.2]{ecma262} or arrow function~\cite[Sect. 15.3]{ecma262}.
The codeblock of a \texttt{do} expression has one major difference from these equivalent functions, as it allows for implicit return of the final statement of the block, and is the resulting value of the entire \texttt{do} expression. The local scoping of this feature allows for a cleaner environment in the parent scope of the \texttt{do} expression. What is meant by this is for temporary variables and other assignments used once can be enclosed inside a limited scope within the \texttt{do} block. Allowing for a cleaner environment inside the parent scope where the \texttt{do} block is defined.
The current version of JavaScript enables the use of immediately invoked arrow functions with no arguments to achieve similar behavior to ``Do Expression'', an example of this can be seen in the Listing below. The main difference between immediately invoked arrow functions and ``Do Expression'' is the final statement/expression will implicitly return its Completion Record~\cite[Sect. 6.2.4]{ecma262}, and we de not need a return statement.
The current version of JavaScript enables the use of immediately invoked arrow functions with no arguments to achieve similar behavior to ``Do expression'', an example of this can be seen in the Listing below. The main difference between immediately invoked arrow functions and ``Do expression'' is the final statement/expression will implicitly return its Completion Record~\cite[Sect. 6.2.4]{ecma262}, and we de not need a return statement.
\noindent\begin{minipage}{.45\textwidth}
\begin{lstlisting}[language={JavaScript}]
@ -306,7 +306,7 @@ let x = do {
\end{lstlisting}
\end{minipage}\hfil
The example below is very similar to the one above, and uses an unnamed function~\cite[15.2]{ecma262} which is invoked immediately to produce similar behavior to the ``Do Expression'' proposal.
The example below is very similar to the one above, and uses an unnamed function~\cite[15.2]{ecma262} which is invoked immediately to produce similar behavior to the ``Do expression'' proposal.
\noindent\begin{minipage}{.45\textwidth}
\begin{lstlisting}[language={JavaScript}]
@ -545,11 +545,11 @@ In this section, we present specifications of the proposals described in Section
This is because this tool is designed to be used by TC39 to gather feedback from user's on proposals during development. This use case means the specifications should be defined in a way that showcases the proposal. This also means it is important the transformation is correct, as incorrect transformations might lead to bad feedback on a proposal.
\subsection{"Pipeline" Proposal}
\subsection{``Pipeline'' Proposal}
This proposal is applicable to call expressions, and is aimed at improving code readability when performing deeply nested function calls.
\begin{lstlisting}[language={JavaScript}, caption={Example of "Pipeline" proposal definition in \DSL{}.}, label={def:pipeline}]
\begin{lstlisting}[language={JavaScript}, caption={Example of ``Pipeline'' proposal definition in \DSL{}.}, label={def:pipeline}]
proposal Pipeline {
case SingleArgument {
@ -578,7 +578,7 @@ In the Listing \ref{def:pipeline}, the first \texttt{case} definition \texttt{Si
\subsection{``Do Expression'' Proposal}
The ``Do Expression'' proposal~\cite{Proposal:DoProposal} focuses on bringing expression-oriented programming to JavaScript.
The ``Do expression'' proposal~\cite{Proposal:DoProposal} focuses on bringing expression-oriented programming to JavaScript.
\begin{lstlisting}[language={JavaScript}, caption={Definition of Do Proposal in \DSL{}.}, label={def:doExpression}]
proposal DoExpression{
@ -615,14 +615,14 @@ proposal DoExpression{
}
\end{lstlisting}
In Listing \ref{def:doExpression}, the specification of ``Do Expression'' proposal in \DSL{} can be seen. It has two cases: the first case \texttt{arrowFunction} applies to code using an immediately invoked arrow function~\cite[15.3]{ecma262} with a return value. The wildcard \texttt{statements} matches against one or more statements that are not of type \texttt{ReturnStatement}. The reason we limit the wildcard is we cannot match the final statement of the block to this wildcard, as that has to be matched against the return statement in the template. The second wildcard \texttt{returnVal} matches against any expressions; the reason for extracting the expression from the \texttt{return} statement, is to use it in the implicit return of the \texttt{do} block. In the transformation template, we replace the arrow function with with a \texttt{do} expression. This expression has to be defined inside parenthesis, as a free floating \texttt{do} expression is not allowed due to ambiguous parsing against a \texttt{do while} statement. We insert the statements matched against \texttt{statements} wildcard into the block of the \texttt{do} expression, and the final statement of the block is the expression matched against the \texttt{returnVal} wildcard. This will transform an arrow function into a \texttt{do} expression.
In Listing \ref{def:doExpression}, the specification of ``Do expression'' proposal in \DSL{} can be seen. It has two cases: the first case \texttt{arrowFunction} applies to code using an immediately invoked arrow function~\cite[15.3]{ecma262} with a return value. The wildcard \texttt{statements} matches against one or more statements that are not of type \texttt{ReturnStatement}. The reason we limit the wildcard is we cannot match the final statement of the block to this wildcard, as that has to be matched against the return statement in the template. The second wildcard \texttt{returnVal} matches against any expressions; the reason for extracting the expression from the \texttt{return} statement, is to use it in the implicit return of the \texttt{do} block. In the transformation template, we replace the arrow function with with a \texttt{do} expression. This expression has to be defined inside parenthesis, as a free floating \texttt{do} expression is not allowed due to ambiguous parsing against a \texttt{do while} statement. We insert the statements matched against \texttt{statements} wildcard into the block of the \texttt{do} expression, and the final statement of the block is the expression matched against the \texttt{returnVal} wildcard. This will transform an arrow function into a \texttt{do} expression.
The second case \texttt{unnamedFunction} follows the same principle as the first case, but is applied to immediately invoked unnamed functions, and produces the exact same output after the transformation as the first case. This is because immediately invoked unnamed functions are equivalent to arrow functions.
\subsection{"Await to Promise" imaginary proposal}
\subsection{`Await to promise'' imaginary proposal}
\begin{lstlisting}[language={JavaScript}, caption={Definition of Await to Promise evaluation proposal in \DSL{}.}, label={def:awaitToPromise}]
\begin{lstlisting}[language={JavaScript}, caption={Definition of ``Await to promise'' evaluation proposal in \DSL{}.}, label={def:awaitToPromise}]
proposal awaitToPomise{
case single{
applicable to {
@ -642,7 +642,7 @@ proposal awaitToPomise{
}
\end{lstlisting}
The specification of "Await to Promise" in \DSL{} is created to match asynchronous code inside a function. It is limited to match asynchronous functions containing a single await statement, and that await statement has to be stored in a \texttt{VariableDeclaration}. The second wildcard \texttt{statements} is designed to match all statements following the \texttt{await} statement up to the return statement. This is done to move the statements into the callback function of \texttt{then()} in the transformation. We include \texttt{\!ReturnStatement} because we do not want to consume the return as it would then be removed from the functions scope and into the callback function of \texttt{then()}. We also have to avoid matching where there exists loop specific statements such as \texttt{ContinueStatement} or \texttt{BreakStatement}.
The specification of ``Await to promise'' in \DSL{} is created to match asynchronous code inside a function. It is limited to match asynchronous functions containing a single await statement, and that await statement has to be stored in a \texttt{VariableDeclaration}. The second wildcard \texttt{statements} is designed to match all statements following the \texttt{await} statement up to the return statement. This is done to move the statements into the callback function of \texttt{then()} in the transformation. We include \texttt{\!ReturnStatement} because we do not want to consume the return as it would then be removed from the functions scope and into the callback function of \texttt{then()}. We also have to avoid matching where there exists loop specific statements such as \texttt{ContinueStatement} or \texttt{BreakStatement}.
The transformation definition has to use an async arrow function as argument for \texttt{then}, as there might be more await expressions contained within \texttt{statements}.

2
chapter/ch4.tex
View file

@ -159,7 +159,7 @@ To refer to internal DSL variables defined in \texttt{applicable to} and \texttt
\subsection*{Why not use Langium for wildcard parsing?}
Langium has support for creating a generator to output an artifact, which is some transformation applied to the AST built by the Langium parser. This suits the needs of \DSL{} quite well and could be used to extract the wildcards and parse the type expressions. This is the way the developers of Langium want this kind of functionality to be implemented, however, the implementation would still be mostly the same, as the parsing of the wildcards still has to be done "manually" with a custom parser. Therefore, we decided for this project to keep the parsing of the wildcards separate. If we were to use Langium generators to parse the wildcards, it would make \DSL{}SH dependent on Langium. This is not preferred as that would mean both ways of defining a proposal are reliant of Langium. The reason for using our own extractor is to allow for an independent way to define transformations using our tool.
Langium has support for creating a generator to output an artifact, which is some transformation applied to the AST built by the Langium parser. This suits the needs of \DSL{} quite well and could be used to extract the wildcards and parse the type expressions. This is the way the developers of Langium want this kind of functionality to be implemented, however, the implementation would still be mostly the same, as the parsing of the wildcards still has to be done ``manually'' with a custom parser. Therefore, we decided for this project to keep the parsing of the wildcards separate. If we were to use Langium generators to parse the wildcards, it would make \DSL{}SH dependent on Langium. This is not preferred as that would mean both ways of defining a proposal are reliant of Langium. The reason for using our own extractor is to allow for an independent way to define transformations using our tool.
\subsection*{Extracting wildcards from \DSL{}}