65 lines
No EOL
4.9 KiB
TeX
65 lines
No EOL
4.9 KiB
TeX
\section{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.
|
|
|
|
\subsection{The core idea}
|
|
|
|
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-exisiting 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.
|
|
|
|
% Should this be moved to chapter 2?
|
|
A proposal for EcmaScript is a suggestion for a change to the language. These changes come with a set of problems that if the proposal is included as a part of EcmaScript, those problems should be solved by utilizing the additions contained within the proposal.
|
|
|
|
Further in this chapter, we will be discussing the \textit{old} and \textit{new} way of solving a problem. What we are referring to in this case is whatever 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 \textit{new} way of solving said problems. The \textit{old} way is the current status quo when the proposal is not part of EcmaScript, and the \textit{new} way is when the proposal is part of EcmaScript and we are utilizing the new features of said proposal.
|
|
|
|
\subsection{Applying a proposal}
|
|
|
|
The way this project will use the pre-existing knowledge the user harbors of their own code is to use it as a base, and \textit{apply} the proposal to that base.
|
|
|
|
When a proposal is \textit{applied} to a piece of code there are some main steps. A code snippet where the proposal might be used has to be identified. That same code snippet has to be transformed to use the new features the proposal implements. Then both the original and the transformed code snippet has to be showcased to the user.
|
|
|
|
Identifying a code snippet where the proposal might be utilized, the problem a proposal is solving allows us to iden
|
|
|
|
\subsection{Syntactic proposal}
|
|
|
|
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, one such example is a Syntactic proposal
|
|
|
|
A syntactic proposal, is a proposal that contains only changes to the syntax of a language. This means, the proposal contains either no, or very limited change to functionality, and no changes to semantics.
|
|
|
|
This is an example of a very simple syntactic proposal.
|
|
|
|
Consider a imaginary proposal \exProp. This proposal describes adding an optional keyword for declaring numerical variables if the expression of the declaration is a numerical literal.
|
|
|
|
This proposal will look something like this:
|
|
|
|
\begin{lstlisting}[language={JavaScript}, caption={Example of imaginary proposal \exProp}, label={ex:proposal}]
|
|
// Original code
|
|
let x = 100;
|
|
let b = "Some String";
|
|
let c = 200;
|
|
|
|
// Code after application of proposal
|
|
int x = 100;
|
|
let b = "Some String";
|
|
let c = 200;
|
|
\end{lstlisting}
|
|
|
|
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{Showcasing syntactic proposals}
|
|
|
|
The application of a proposal on a program will then be utilized as a way of presenting the proposal to developers using EcmaScript(hereby referred to as users). If the code used for the application is already familiar to the user, we can severely limit the amount of time spent to understand the functionality of the initial code used in the application of the proposal. This allows the users more focus on the actual change presented by the proposal, which in turn might present itself in better feedback on the proposal, as well as presenting issues about the proposal earlier in the process.
|
|
|
|
|
|
This showcase is done by, The user being presented with two pieces of code. One being the original version with no changes, and the other being the transformed code after, this will allow the user to see how it was written before, and see how the proposal could have been applied here. This will give a low barrier of entry to understand a proposal and give meaningful feedback to the committee.
|
|
|
|
This paper does not focus on showcasing and gathering user feedback, however focusing more on the process of applying a proposal to some piece of code, while maintaining its functionality.
|
|
|
|
|
|
\subsection{\DSL}
|
|
|
|
In order to match ......
|
|
|
|
|
|
\subsection{Using the \DSL with an actual syntactic proposal} |