diff --git a/build/report.pdf b/build/report.pdf index 1a0bf63..ff1e885 100644 Binary files a/build/report.pdf and b/build/report.pdf differ diff --git a/chapter/ch3.tex b/chapter/ch3.tex index bef9038..7844762 100644 --- a/chapter/ch3.tex +++ b/chapter/ch3.tex @@ -1,34 +1,34 @@ \chapter{Collecting User Feedback for Syntactic Proposals} The goal for this project is to utilize users familiarity with their own code to gain early and worthwhile user feedback on new -syntactic proposals for EcmaScript. +syntactic proposals for ECMAScript. \section{The core idea} -When a use of EcmaScript wants to suggest a change to the language, the idea of the change has to be described in a Proposal. A proposal is a general way of describing a change and its requirements, this is done by a language specification, motivation for the idea, and general discussion around the proposed change. A proposal ideally also needs backing from the community of users that use EcmaScript, this means the proposal has to be presented to users some way. This is currently done by many channels, such as polyfills, code examples, and as beta features of the main JavaScript engines, however, this paper wishes to showcase proposals to users by using a different avenue. +When a use of ECMAScript wants to suggest a change to the language, the idea of the change has to be described in a Proposal. A proposal is a general way of describing a change and its requirements, this is done by a language specification, motivation for the idea, and general discussion around the proposed change. A proposal ideally also needs backing from the community of users that use ECMAScript, this means the proposal has to be presented to users some way. This is currently done by many channels, such as polyfills, code examples, and as beta features of the main JavaScript engines, however, this paper wishes to showcase proposals to users by using a different avenue. -Users of EcmaScript have a familiarity with code they themselves have written. This means they have knowledge of how their own code works and why they might have written it a certain way. This project aims to utilize this pre-existing knowledge to showcase new proposals for EcmaScript. Showcasing proposals this way will allow users to focus on what the proposal actually entails, instead of focusing on the examples written by the proposal author. +Users of ECMAScript have a familiarity with code they themselves have written. This means they have knowledge of how their own code works and why they might have written it a certain way. This project aims to utilize this pre-existing knowledge to showcase new proposals for ECMAScript. This way will allow users to focus on what the proposal actually entails, instead of focusing on the examples written by the proposal authors. -Further in this chapter, we will be discussing the current version and future version of EcmaScript. What we are referring to in this case is with set of problems a proposal is trying to solve, if that proposal is allowed into EcmaScript as part of the language, there will be a future way of solving said problems. The current way is the current status quo when the proposal is not part of EcmaScript, and the future version is when the proposal is part of EcmaScript and we are utilizing the new features of said proposal. +Further in this chapter, we will be discussing the current version and future version of ECMAScript. What we are referring to in this case is with set of problems a proposal is trying to solve, if that proposal is allowed into ECMAScript as part of the language, there will be a future way of solving said problems. The current way is the current status quo when the proposal is not part of ECMAScript, and the future version is when the proposal is part of ECMAScript and we are utilizing the new features of said proposal. -The program will allow the users to preview proposals way before they are part of the language. This way the committee can get useful feedback from users of the language earlier in the proposal process. Using the users familiarity will ideally allow for a more efficient process developing EcmaScript. +The program will allow the users to preview proposals way before they are part of the language. This way the committee can get useful feedback from users of the language earlier in the proposal process. Using the users familiarity will ideally allow for a more efficient process developing ECMAScript. \subsection{Applying a proposal} The way this project will use the pre-existing knowledge a user has of their own code is to use that code as base for showcasing a proposals features. Using the users own code as base requires the following steps in order to automatically implement the examples that showcase the proposal inside the context of the users own code. -The ide is to identify where the features and additions of a proposal could have been used. This means identifying parts of the users program that use pre-existing EcmaScript features that the proposal is interacting with and trying to solve. This will then identify all the different places in the users program the proposal can be applied. This step is called \textit{matching} in the following chapters +The ide is to identify where the features and additions of a proposal could have been used. This means identifying parts of the users program that use pre-existing ECMAScript features that the proposal is interacting with and trying to solve. This will then identify all the different places in the users program the proposal can be applied. This step is called \textit{matching} in the following chapters Once we have matched all the parts of the program the proposal could be applied to, the users code has to be transformed to use the proposal, this means changing the code to use a possible future version of JavaScript. This step also includes keeping the context and functionality of the users program the same, so variables and other context related concepts have to be transferred over to the transformed code. -The output of the previous step is then a set of code pairs, where one a part of the users original code, and the second is the transformed code. The transformed code is then ideally a perfect replacement for the original user code if the proposal is part of EcmaScript. These pairs are used as examples to present to the user, presented together so the user can see their original code together with the transformed code. This allows for a direct comparison and an easier time for the user to understand the proposal. +The output of the previous step is then a set of code pairs, where one a part of the users original code, and the second is the transformed code. The transformed code is then ideally a perfect replacement for the original user code if the proposal is part of ECMAScript. These pairs are used as examples to present to the user, presented together so the user can see their original code together with the transformed code. This allows for a direct comparison and an easier time for the user to understand the proposal. -The steps outlined in this section require some way of defining matching and transforming of code. This has to be done very precisely and accurately in order to avoid examples that are wrong. Imprecise definition of the proposal might lead to transformed code not being a direct replacement for the code it was based upon. For this we suggest two different methods, a definition written in a custom DSL \DSL and a definition written in a self-hosted way only using EcmaScript as a language as definition language. Read more about this in SECTION HERE. +The steps outlined in this section require some way of defining matching and transforming of code. This has to be done very precisely and accurately in order to avoid examples that are wrong. Imprecise definition of the proposal might lead to transformed code not being a direct replacement for the code it was based upon. For this we suggest two different methods, a definition written in a custom DSL \DSL and a definition written in a self-hosted way only using ECMAScript as a language as definition language. Read more about this in SECTION HERE. \section{Applicable proposals} \label{sec:proposals} -A proposal for EcmaScript is a suggested change for the language, in the case of EcmaScript this comes in the form of an addition to the language, as EcmaScript does not allow for breaking changes. There are many different kinds of proposals, this project focuses exclusively on Syntactic Proposals. +A proposal for ECMAScript is a suggested change for the language, in the case of ECMAScript this comes in the form of an addition to the language, as ECMAScript does not allow for breaking changes. There are many different kinds of proposals, this project focuses exclusively on Syntactic Proposals. \subsection{Syntactic Proposals} @@ -56,7 +56,7 @@ See that in \ref{ex:proposal} the change is optional, and is not applied to the \subsection{\cite{Proposal:DiscardBindings}{Discard Bindings}} -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. +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. Unpacking when doing an assignment refers to assigning internal fields of an object/array directly in the assignment rather than using a temporary variable. See \ref{ex:unpackingObject} for an example of unpacking an object and \ref{ex:unpackingArr}. @@ -83,11 +83,11 @@ let [a, b, _1, _2] = [ 0, 2, 3, 4 ]; // a = 0, b = 2, _1 = 3, _2 = 4 -In EcmaScripts current form, it is required to assign every part of an unpacked object/array to some identifier. The current status quo is to use \_ as a sign it is meant to be discarded. This proposal suggests a specific keyword \textit{void} to be used as a signifier whatever is at that location should be discarded. +In ECMAScripts current form, it is required to assign every part of an unpacked object/array to some identifier. The current status quo is to use \_ as a sign it is meant to be discarded. This proposal suggests a specific keyword \textit{void} to be used as a signifier whatever is at that location should be discarded. -This feature is present in other languages, such as Rust wildcards, Python wildcards and C\# using statement and discards. In most of these other languages, the concept of discard is a single \_. In EcmaScript the \_ token is a valid identifier, therefore this proposal suggests the use of the keyword \textit{void}. This keyword is already is reserved as part of function definitions where a function is meant to have no return value. +This feature is present in other languages, such as Rust wildcards, Python wildcards and C\# using statement and discards. In most of these other languages, the concept of discard is a single \_. In ECMAScript the \_ token is a valid identifier, therefore, this proposal suggests the use of the keyword \textit{void}. This keyword is already is reserved as part of function definitions where a function is meant to have no return value. -This proposal allows for the \textit{void} keyword to be used in a variety of contexts. Some simpler than others but all following the same pattern of allowing discarding of bindings to an identifier. It is allowed anywhere the \textit{BindingPattern}, \textit{LexicalBinding} or \textit{DestructuringAssignmentTarget} features are used in EcmaScript. This means it can be applied to unpacking of objects/arrays, in callback parameters and class methods. +This proposal allows for the \textit{void} keyword to be used in a variety of contexts. Some simpler than others but all following the same pattern of allowing discarding of bindings to an identifier. It is allowed anywhere the \textit{BindingPattern}, \textit{LexicalBinding} or \textit{DestructuringAssignmentTarget} features are used in ECMAScript. This means it can be applied to unpacking of objects/arrays, in callback parameters and class methods. \begin{lstlisting}[language={JavaScript}, caption={Example discard binding with variable discard}] using void = new UniqueLock(mutex); @@ -185,26 +185,29 @@ await using void = x; // via: LexicalBinding : `void` Initializer \subsection{Pipeline Proposal} -The pipeline proposal is a Syntactic proposal with no change to functionality of EcmaScript, it focuses solely on solving problems related to nesting of function calls and other expressions that allow for a topic reference. A topic reference is a reference to some value based on the current context/topic. +The Pipeline proposal \cite{Pipeline} is a syntactic proposal which focuses on solving problems related to nesting of function calls and other expressions that take an expression as an argument. -The pipeline proposal aims to solve two problems with performing consecutive operations on a value. In EcmaScript there are two main styles of achieving this functionality currently. Nesting calls and chaining calls, these two come with a differing set of challenges when used. +This proposal aims to solve two problems with performing consecutive operations on a value. In ECMAScript there are two main styles of achieving this functionality currently: nesting calls and chaining calls, each of them come with a differing set of challenges when used. Nesting calls is mainly an issue related to function calls with one or more arguments. When doing many calls in sequence the result will be a \textit{deeply nested} call expression. -Nested calls has some specific challenges when relating to readability when used. The order of calls go from right to left, which is opposite of the natural reading direction a lot of the users of EcmaScript are used to day to day, this means it is difficult switch reading direction when working out which call happens in which order. When using functions with multiple arguments in the middle of the nested call, it is not intuitive to see what call its arguments belong to, this is also a problem with readability of nested calls, which is the main challenge this proposal is trying to solve. Nested calls are not all bad however, one of the main good points of nested calls is they can be simplified by using temporary variables, while this does introduce its own set of issues, it provides some way of mitigating the readability problem. Another positive side of nested calls is they do not require a specific design to be used, a library developer does not have to design their library around this specific call style. - - +Using nested calls has some specific challenges related to readability when used. The order of calls go from right to left, which is opposite of the natural reading direction a lot of the users of ECMAScript are used to day to day. This means it is difficult to switch the reading direction when working out which call happens in which order. When using functions with multiple arguments in the middle of the nested call, it is not intuitive to see what call its arguments belong to. These issues are the main challenges this proposal is trying to solve. On the other hand, nested calls can be simplified by using temporary variables. While this does introduce its own set of issues, it provides some way of mitigating the readability problem. Another positive side of nested calls is they do not require a specific design to be used, and a library developer does not have to design their library around this specific call style. +\noindent\begin{minipage}{.45\textwidth} \begin{lstlisting}[language={JavaScript}] // Deeply nested call with single arguments -function1(function2(function3(function4(value)))); +f1(f2(f3(f4(v)))); -// Deeply nested call with multi argument functions -function1(function2(function3(value2, function4)), value1); \end{lstlisting} +\end{minipage}\hfil +\noindent\begin{minipage}{.45\textwidth} +\begin{lstlisting}[language={JavaScript}] +// Deeply nested call with multi argument functions +f1(v5, f2(f3(v3, f4(v1, v2)), v4), v6); +\end{lstlisting} +\end{minipage}\hfil - -Chaining solves some of the issues relating to nesting, as it allows for a more natural reading direction left to right when identifying the sequence of call, arguments are naturally grouped together with their respoective function call, and it provides a way of untangling deep nesting. However, solving consecutive operations using chaining has its own set of challenges when used. In order to use chaining, the api of the code you are trying to call has to be designed to allow for chaining. This is not always the case, making using chaining when it is not been designed specifically for very difficult. There are also concepts in JavaScript not supported when using chaining, such as arithmetic operations, literals, await, yield and so on. This is actually the biggest downside of chaining, as it only allows for function calls when used, and if one wants to allow for use of other concepts temporary variables have to be used. +Chaining solves some of these issues: indeed, as it allows for a more natural reading direction left to right when identifying the sequence of call, arguments are naturally grouped together with their respective function call, and it provides a way of untangling deep nesting. However, executing consecutive operations using chaining has its own set of challenges when used. In order to use chaining, the API of the code being called has to be designed to allow for chaining. This is not always the case however, making use of chaining when it has not been specifically designed for can be very difficult. There are also concepts in JavaScript not supported when using chaining, such as arithmetic operations, literals, \texttt{await} expressions, \texttt{yield} expressions and so on. This proves to be a significant downside of chaining, as it only allows for function calls when used, and if one wants to allow for use of other concepts temporary variables have to be used. \begin{lstlisting}[language={JavaScript}] // Chaining calls @@ -214,11 +217,13 @@ function1().function2().function3(); function1(value1).function2().function3(value2).function4(); \end{lstlisting} -The pipeline proposal aims to combine the benefits of these two styles without all the challenges each method faces. +The Pipeline proposal\cite{Pipeline} aims to combine the benefits of these two styles without the challenges each method faces. -The main benefit of pipeline is to allow for a similar style to chaining when chaining has not been specifically designed to be applicable. The idea uses syntactic sugar to change the order of writing the calls without influencing the API of the functions. Doing this allows each call to come in the direction of left to right, while still maintaining the modularity of deeply nested function calls. +The main benefit of the proposal is to allow for a similar style to chaining when chaining has not been specifically designed to be applicable. The essential 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 way the pipeline proposal aims to solve this is to introduce a pipe operator, which takes the result of an expression on the left, and \textit{pipes} it into an expression on the right. The location of where the result is piped to is where the \textit{topic token} is located. All the specifics of the exact token used as a \textit{topic token} and exactly what operator will be used as the pipe operator might be subject to change. +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}. + +The code snippets below showcase the machinery of the proposal. \noindent\begin{minipage}{.45\textwidth} \begin{lstlisting}[language={JavaScript}] @@ -277,15 +282,18 @@ return xf \end{lstlisting} \end{minipage}\hfil -\subsection{Do proposal} +The pipe operator is not a new concept, and is present in many other languages such as F\# \cite{FPipeOperator} and Julia\cite{JuliaPipe} where the pipe operator is \texttt{|\>}. The main difference between the Julia and F\# pipe operator compared to this proposal, is the result of the left side expression has to be piped into a function with a single argument, the proposal suggests a topic reference to be used in stead of requiring a function. -The \cite[Do Proposal]{Proposal:DoProposal} is a proposal meant to bring \textit{expression oriented} programming to EcmaScript. Expression oriented programming is a concept taken from functional programming which allows for combining expressions in a very free manor allowing for a highly malleable programming experience. +\subsection{Do Expressions} -The motivation of the do expression proposal is to create a feature that allows for local scoping of a code block that is treated as an expression. This allows for complex code requiring multiple statements to be confined inside its own scope and the resulting value is returned from the block as an expression. Similar to how a unnamed functions or arrow functions are currently used. The current status quo of how to achieve this behavior is to use unnamed functions and invoke them immediately, or use an arrow function, these two are equivalent to a do expression. +The Do Expressions\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 manor allowing for a highly malleable programming experience. -The codeblock of a do expression has one major difference from these equivalent functions, as it allows for implicit return of the final expression of the block, and is the resulting value of the entire do expression. +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{ScopeECMA-262} and the resulting value is returned from the block implicitly as an expression, similarly to how a unnamed functions or arrow functions are currently used. In order to achieve this behavior in the current stable version of ECMAScript, one needs to use unnamed functions and invoke them immediately, or use an arrow function. + +The codeblock of a \texttt{do} expression has one major difference from these equivalent functions, as it allows for implicit return of the final expression of the block, and is the resulting value of the entire \texttt{do} expression. This gives that the final statement of a \texttt{do} expression has to contain a completion value \cite{CompletionRecord}, where the value will be the result of the expression, and cannot be an \texttt{if} without an \texttt{else}, a loop, or a variable declaration. + +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 local scoping of this feature allows for a cleaner environment in the parent scope of the 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 do block. Allowing for a cleaner environment inside the parent scope where the do block is defined. \noindent\begin{minipage}{.45\textwidth} \begin{lstlisting}[language={JavaScript}] // Current status quo diff --git a/chapter/ch5.tex b/chapter/ch5.tex index fb34d3c..9a2110a 100644 --- a/chapter/ch5.tex +++ b/chapter/ch5.tex @@ -33,7 +33,17 @@ The Do proposal \cite{Proposal:DoProposal} is expected to not find many matches, Await to promise also has an expected number of matches, but this evaluation proposal is not meant to be real life representative. As it is limited to functions containing only a single await statement and that statement has to be a \texttt{VariableDeclaration}. -\paragraph*{Next.js} is one of the largest projects related to JavaScript. It is owned by Vercel and is used as a development platform for the web. +When the amount of files searched is different for each of the proposals, it means either a transformation on that file, or generation of that file failed for some reason. This is probably due to bugs in the transform algorithm that creates this discrepancy. + +\paragraph*{Next.js}\cite{NEXT.JS} is one of the largest projects related to JavaScript. It is owned by Vercel and is used as a development platform for the web. + +\paragraph*{Three.js}\cite{ThreeJS} is a library for 3D rendering in JavaScript. It is written purely in JavaScript and uses GPU for 3D calculations. It being a popular JavaScript library, and being written in mostly pure JavaScript makes it a good case study for our tool. It currently sits at over 1 million downloads weekly. + +\paragraph*{React}\cite{React} is a graphical user interface library for JavaScript, it facilitates the creation of user interfaces for both web and native platforms. React is based upon splitting a user interface into components for simple development. It is currently one of the most popular libraries for creating web apps and has over 223000 stars on Github. + +\paragraph*{Bootstrap}\cite{Bootstrap} is a front-end framework used for creating responsive and mobile-first websites, it comes with a variety of built-in components, as well as a built in styling. This styling is also customizable using CSS. This library is a good evaluation point for this thesis as it is written in pure JavaScript and is used by millions of developers. + +\paragraph*{Atom}\cite{Atom} is a text editor made in JavaScript using the Electron framework. It was created to give a very minimal and modular text editor. It was bought by Microsoft, and later discontinued in favor for Visual Studio Code. \begin{figure} \begin{center} @@ -43,7 +53,7 @@ Await to promise also has an expected number of matches, but this evaluation pro \hline \hline Pipeline & 55787 & 1327 & 2331 & 89m 11s \\ \hline - Do & 18 & 15 & 2331 & 2m 12s \\ + Do & 131 & 74 & 2331 & 35s \\ \hline Await to Promise & 43 & 38 & 2331 & 16s \\ \hline @@ -53,8 +63,6 @@ Await to promise also has an expected number of matches, but this evaluation pro \label{fig:evalNextJS} \end{figure} -\paragraph*{Three.js} is a library for 3D rendering in JavaScript. It is written purely in JavaScript and uses GPU for 3D calculations. It being a popular JavaScript library, and being written in mostly pure JavaScript makes it a good case study for our tool. It currently sits at over 1 million downloads weekly. - \begin{figure} \begin{center} \begin{tabular}{|c|c|c|c|c|} @@ -63,7 +71,7 @@ Await to promise also has an expected number of matches, but this evaluation pro \hline \hline Pipeline & 85050 & 1119 & 1262 & 242m 58s \\ \hline - Do & 194 & 26 & 1262 & 6m 23s \\ + Do & 278 & 55 & 1385 & 3m 3s \\ \hline Await to Promise & 125 & 80 & 1262 & 59s \\ \hline @@ -73,8 +81,6 @@ Await to promise also has an expected number of matches, but this evaluation pro \label{fig:evalThreeJS} \end{figure} -\paragraph*{React} is a graphical user interface library for JavaScript, it facilitates the creation of user interfaces for both web and native platforms. React is based upon splitting a user interface into components for simple development. It is currently one of the most popular libraries for creating web apps and has over 223000 stars on Github. - \begin{figure} \begin{center} \begin{tabular}{|c|c|c|c|c|} @@ -83,7 +89,7 @@ Await to promise also has an expected number of matches, but this evaluation pro \hline \hline Pipeline & 16353 & 1266 & 2051 & 84s \\ \hline - Do & 14 & 12 & 2051 & 8s \\ + Do & 79 & 60 & 2051 & 8s \\ \hline Await to Promise & 104 & 88 & 2051 & 6s \\ \hline @@ -93,4 +99,38 @@ Await to promise also has an expected number of matches, but this evaluation pro \label{fig:evalReact} \end{figure} +\begin{figure} +\begin{center} +\begin{tabular}{|c|c|c|c|c|} + \hline + Proposal & Matches found & Files with matches & Files searched & Time\\ + \hline \hline + Pipeline & 13794 & 109 & 115 & 2m 57s \\ + \hline + Do & 13 & 8 & 115 & 3s \\ + \hline + Await to Promise & 0 & 0 & 115 & 2s \\ + \hline +\end{tabular} +\end{center} +\caption{Evaluation with Bootstrap source code} +\label{fig:evalBootstrap} +\end{figure} +\begin{figure} +\begin{center} +\begin{tabular}{|c|c|c|c|c|} + \hline + Proposal & Matches found & Files with matches & Files searched & Time\\ + \hline \hline + Pipeline & 40606 & 361 & 401 & 16m 17s \\ + \hline + Do & 46 & 26 & 401 & 6s \\ + \hline + Await to Promise & 8 & 6 & 401 & 4s \\ + \hline +\end{tabular} +\end{center} +\caption{Evaluation with Atom source code} +\label{fig:evalAtom} +\end{figure} \ No newline at end of file diff --git a/generators/refs.bib b/generators/refs.bib index 42c32be..1f2389b 100755 --- a/generators/refs.bib +++ b/generators/refs.bib @@ -244,4 +244,114 @@ urldate = {2024-05-22}, note = {[Online; accessed 22. May 2024]}, url = {https://www.jetbrains.com/help/idea/structural-search-and-replace.html} +} + +@misc{Atom, + title = {{atom}}, + year = {2024}, + month = may, + urldate = {2024-05-23}, + note = {[Online; accessed 23. May 2024]}, + url = {https://github.com/atom/atom} +} + +@misc{Bootstrap, + title = {{bootstrap}}, + journal = {GitHub}, + year = {2024}, + month = may, + urldate = {2024-05-23}, + note = {[Online; accessed 23. May 2024]}, + url = {https://github.com/twbs/bootstrap} +} + +@misc{React, + title = {{react}}, + journal = {GitHub}, + year = {2024}, + month = may, + urldate = {2024-05-23}, + note = {[Online; accessed 23. May 2024]}, + url = {https://github.com/facebook/react} +} +@misc{NEXT.JS, + title = {{next.js}}, + journal = {GitHub}, + year = {2024}, + month = may, + urldate = {2024-05-23}, + note = {[Online; accessed 23. May 2024]}, + url = {https://github.com/vercel/next.js} +} + +@misc{ThreeJS, + title = {{three.js}}, + journal = {GitHub}, + year = {2024}, + month = may, + urldate = {2024-05-23}, + note = {[Online; accessed 23. May 2024]}, + url = {https://github.com/mrdoob/three.js} +} +@misc{PipelineBikeshedding, + title = {{Bikeshedding the Hack topic token {$\cdot$} Issue {\#}91 {$\cdot$} tc39/proposal-pipeline-operator}}, + journal = {GitHub}, + year = {2024}, + month = may, + urldate = {2024-05-24}, + note = {[Online; accessed 24. May 2024]}, + url = {https://github.com/tc39/proposal-pipeline-operator/issues/91} +} + +@misc{FPipeOperator, + author = {KathleenDollard}, + title = {{Symbol and Operator Reference - F{\#}}}, + year = {2024}, + month = may, + urldate = {2024-05-24}, + note = {[Online; accessed 24. May 2024]}, + url = {https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/symbol-and-operator-reference/#type-symbols-and-operators} +} + +@misc{JuliaPipe, + title = {{Functions {$\cdot$} The Julia Language}}, + year = {2024}, + month = may, + urldate = {2024-05-24}, + note = {[Online; accessed 24. May 2024]}, + url = {https://docs.julialang.org/en/v1/manual/functions/#Function-composition-and-piping} +} + +@article{ExpressionOriented, + author = {Bantchev, Boyko B.}, + title = {{Putting more meaning in expressions}}, + journal = {SIGPLAN Not.}, + volume = {33}, + number = {9}, + pages = {77--83}, + year = {1998}, + month = sep, + urldate = {2024-05-24}, + issn = {0362-1340}, + publisher = {Association for Computing Machinery}, + url = {https://dl.acm.org/doi/10.1145/290229.290237}, + doi = {10.1145/290229.290237} +} + +@misc{ScopeECMA-262, + title = {{ECMAScript{\ifmmode\circledR\else\textregistered\fi} 2025 Language Specification}}, + year = {2024}, + month = may, + urldate = {2024-05-24}, + note = {[Online; accessed 24. May 2024]}, + url = {https://tc39.es/ecma262/#sec-syntax-directed-operations-scope-analysis} +} + +@misc{CompletionRecord, + title = {{ECMAScript{\ifmmode\circledR\else\textregistered\fi} 2025 Language Specification}}, + year = {2024}, + month = may, + urldate = {2024-05-24}, + note = {[Online; accessed 24. May 2024]}, + url = {https://tc39.es/ecma262/#sec-completion-record-specification-type} } \ No newline at end of file