git » jacl.git » commit 6109503

diff --git a/paper/jacl-els-2020.tex b/paper/jacl-els-2020.tex
index fd9485c..08a6842 100644
--- a/paper/jacl-els-2020.tex
+++ b/paper/jacl-els-2020.tex
@@ -31,19 +31,11 @@
   Lisp. JACL --- which is under active development and approaching
   utility --- is an effort to facilitate the use of Common Lisp in
   overcoming the challenges of Single-page Web Application (SPA)
-  development.
-
-  Single-page Web Applications (SPAs) are a popular technique for
-  implementing responsive Web-based User Interfaces (UIs). Google's
-  GMail, introduced in 2007, was one of the first well-known
-  SPAs. SPAs are most commonly implemented in JavaScript or with a
-  language that compiles to JavaScript.
-
-  Despite their ubiquity, SPAs continue to present a wide set of
-  challenges to application developers. These challenges include the
-  limitations imposed by the browser's security model, the
-  asynchronous nature of I/O in JavaScript, and the difficulties
-  inherent in managing large code bases.
+  development. JACL promotes interactive development in the Web
+  browser environment with its \emph{asynchronous reader} and Chrome
+  DevTools-based REPL client. JACL also includes an optimizing
+  Lisp-to-JavaScript compiler capable of generating competitively
+  small and efficient JavaScript.
 \end{abstract}
 
 \begin{CCSXML}
@@ -96,11 +88,6 @@ Lisp, is not. Compared to similar languages that \emph{are} Lisps,
 JACL differentiates itself in two particular ways: with its approach
 to the REPL, and with its compilation techniques.
 
-In this paper, similar efforts will first be surveyed. Then, novel
-aspects of JACL's design and implementation with respect to those
-efforts will be introduced. Finally, conclusions will be drawn and
-future work will be outlined.
-
 \section{Related Work}
 
 Many Lisps exist that either compile to JavaScript or are interpreted
@@ -110,16 +97,15 @@ of Common Lisp are featured.
 
 \subsection{Parenscript}
 
-Released in 2005\cite{Baringer05}, Parenscript\footnote{Also known as
-  ParenScript.}\cite{ParenScriptManual} was the first Common Lisp
-compiler to target JavaScript. Parenscript is not bootstrapped and its
-compiler is not written in JavaScript, and so it relies on a hosting
-Common Lisp system for compilation. Only JavaScript types are
-available to Parenscript programs at runtime, and so Parenscript is
-more of a syntax frontend for JavaScript than it is an interactive
-Lisp system. While Parenscript is not positioned to facilitate
-large-scale SPA development, it remains a popular way to add dynamic
-JavaScript-based behaviors to static Web sites.
+Released in 2005\cite{Baringer05}, Parenscript\cite{ParenScriptManual}
+was the first Common Lisp compiler to target JavaScript. Parenscript
+is not bootstrapped and its compiler is not written in JavaScript, and
+so it relies on a hosting Common Lisp system for compilation. Only
+JavaScript types are available to Parenscript programs at runtime, and
+so Parenscript is more of a syntax frontend for JavaScript than it is
+an interactive Lisp system. While Parenscript is not positioned to
+facilitate large-scale SPA development, it remains a popular way to
+add dynamic JavaScript-based behaviors to static Web sites.
 
 \subsection{SLip}
 
@@ -162,23 +148,21 @@ JSCL supports reading from string-backed pseudo-streams. Input streams
 from which characters may be synchronously consumed are not an
 abstraction supported by JavaScript in Web browsers. With a few
 obscure exceptions\footnote{\texttt{window.prompt()} and
-  \texttt{window.confirm()}.}, JavaScript programs may only receive
-input asynchronously. An error is signaled if the end of a
-string-backed input stream is encountered before the reader has
-finished reading a datum.
+  \texttt{window.confirm()} are two JavaScript functions that may be
+  used to synchronously query the user for input.}, JavaScript
+programs may only receive input asynchronously. An error is signaled
+if the end of a string-backed input stream is encountered before the
+reader has finished reading a datum.
 
 Because input strings may not contain partial data, the REPL
 necessitates a ``pre''-reader process that accumulates characters in
 response to asynchronous input events, and invokes the reader only
 once a complete form --- as a string --- has been accumulated. Such a
 pre-reader can be found in the JSCL REPL implementation. It handles
-standard Lisp atoms and list syntax, but has the potential to be
-stymied by extended syntax, such as that added by reader macros. As
-such, the pre-reader is a separate, degenerate reader that limits
-what's capable of being read by the underlying, full-featured
-synchronous reader. SLip's reader is also synchronous, and its Emacs
-clone, Ymacs, also includes a pre-reader as part of its Lisp
-interaction mode.
+standard syntax, but has the potential to be stymied by extended
+syntax, such as that added by reader macros. As such, the pre-reader
+is a separate, degenerate reader that limits what's capable of being
+read by the underlying, full-featured synchronous reader.
 
 \subsubsection{Compiler organization}
 
@@ -197,9 +181,8 @@ Syntax Trees (AST), is where the implementation of Lisp's special
 forms in terms of JavaScript language constructs and runtime support
 is performed. This is done in a single pass in which macro expansion,
 lexical analysis, and JavaScript AST generation all occur. The lexical
-environment is maintained in a \emph{special}\footnote{Special in the
-  Lisp sense; it has dynamic scope.} variable as the compiler descends
-into Lisp code and produces JavaScript AST.
+environment is maintained in a dynamically-scoped variable as the
+compiler descends into Lisp code and produces JavaScript AST.
 
 Code for \texttt{TAGBODY} is generated in the first stage, and the
 generated code is much slower than comparable JavaScript code for