git » jacl.git » commit e595fff

paper

author Alan Dipert
2020-02-10 06:19:47 UTC
committer Alan Dipert
2020-02-10 06:19:47 UTC
parent e51c85d9e8048c5d84f0d1d86dc4d8ffbe13691e

paper

paper/jacl-els-2020.tex +88 -53

diff --git a/paper/jacl-els-2020.tex b/paper/jacl-els-2020.tex
index fab3a7b..f7eee58 100644
--- a/paper/jacl-els-2020.tex
+++ b/paper/jacl-els-2020.tex
@@ -44,16 +44,19 @@
   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 (JS) or with
-  a language that compiles to JavaScript.
+  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.
+  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.
 
   In this paper I introduce JavaScript-Assisted Common Lisp (JACL), a
   new Web-browser based implementation of an extended subset of Common
-  Lisp (CL). JACL, which is incomplete and under active development,
-  is an attempt to facilitate the use of CL in overcoming the
+  Lisp. JACL --- which is incomplete and under active development ---
+  is an effort to facilitate the use of Common Lisp in overcoming the
   challenges of SPA development.
 \end{abstract}
 
@@ -103,61 +106,37 @@
 
 \section{Introduction}
 
-The demand for SPAs in the past decade has only grown. Users and
+The demand for SPAs in the past decade has only grown, and users and
 stakeholders continually expect larger and more sophisticated
-SPAs. Unfortunately, large-scale UI development presents a particular
-set of challenges that are not easily overcome.
-
-One challenge is the creation and composition of many different kinds
-of user input and output elements. For such elements to be reusable,
-and for an application's implementation to be comprehensible, these
-elements must share a set of visual, behavioral, and data contracts.
-
-Another challenge is the correct handling of events resulting from
-user activity or received over the network from a Web
-server. Applications must react to these events predictably and
-without corrupting data.
-
-SPA implementors have responded to these and other challenges by
-creating a widening variety of special-purpose programming languages
-that compile to JavaScript. Each new language promotes one or more
+applications. Unfortunately, large-scale development on the Web
+browser platform presents a particular set of challenges that are not
+easily overcome.
+
+Developers have responded to these challenges by creating a widening
+variety of special-purpose programming languages that compile to
+JavaScript. [refs] Each new language promotes one or more
 paradigms, application architectures, or development workflows, and
 claim some advantage relative to the status quo.
 
 This paper presents one new such language, JavaScript-Assisted Common
-Lisp (JACL). JACL is as an implementation of an extended subset of
-Common Lisp (CL).
-
-Unlike contemporary SPA implementation languages, CL is associated
-with a history of innovation in the domain of UI implementation that
-predates even the existence of the Web.
-
-For example, many challenges associated with dynamic UI element
-composition were managed successfully in Lisp as early as the late
-1970s. The MIT Lisp Machine operating system was a dynamic, graphical
-computing environment implemented in Lisp. A system called Flavors was
-applied successfully on the Lisp Machine to the problem of managing a
-large number of UI elements.
-
-The Common Lisp Object System (CLOS), CL's standard facility for
-object-oriented programming, is a direct descendent of Flavors.
-
-Predictably handling UI events without data corruption is another
-challenge that has been approached and overcome using Lisp-based
-software. The Garnet UI development system developed at CMU in the
-late 1980s introduced a declarative, constraint-based model for
-managing complex relationships between UI elements. It was used
-successfully in several applications.
-
-The primary goal of the JACL project is to ease the task of SPA
-development by applying CL --- a proven substrate, as evidenced by the
-preceding examples --- to the challenges now faced by SPA
-implementors. JACL is envisioned as the means to that goal, and to
-have at least the following ancillary affordances:
+Lisp (JACL), an implementation of an extended subset of Common Lisp.
+
+Unlike contemporary languages, Lisp is closely associated with a
+history of innovation in the field of large-scale UI development that
+predates the existence of the Web. [refs Flavors, Garnet] The design
+of Common Lisp is informed pervasively by the lessons learned in
+pursuit of those and other innovations.
+
+The primary goal of the JACL project is to ease SPA development by
+applying Common Lisp --- a proven substrate for UI development success
+--- to the difficult challenges now faced by developers. The JACL
+language is envisioned as the means to that goal, and to have at least
+the following ancillary affordances:
 
 \begin{itemize}
   \item Compelling interactive development experience.
-  \item Ability to load source code from the host filesystem.
+  \item Ability to load code from the host filesystem during
+    development.
   \item Fluent interoperation with external JavaScript libraries.
   \item Ability to produce fast and small deliverable executables.
 \end{itemize}
@@ -166,7 +145,6 @@ In this paper, I will describe JACL's design and the current state of
 its implementation. I will also outline major remaining work, such as
 introduction of the Common Lisp Object System (CLOS) and the ability
 to produce optimized deliverables.
-
 \section{Previous Work}
 
 Many Lisps exist that either compile to JavaScript or are interpreted
@@ -181,8 +159,65 @@ discuss Lisps that meet any of the following criteria:
 
 \subsection{Parenscript}
 
+% https://web.archive.org/web/20051122141019/http://blogs.bl0rg.net/netzstaub/archives/000525.html
+
+Released in 2005 [ref], Parenscript 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. It offers no REPL.
+
+By default, JavaScript generated by Parenscript relies on no
+additional data structures or functionality other than that provided
+natively by JavaScript. Even with this limitation, Parenscript
+supports a surprising amount of Common Lisp, including some lambda
+list support, and support for multiple values.
+
+If runtime support is enabled, a few sequence functions become
+available to Parenscript programs.
+
 \subsection{SLip}
 
+% http://lisperator.net/slip/impl
+
+SLip [ref] is perhaps the most ambitious Common Lisp-on-JavaScript
+system to date. Based originally on the compiler and bytecoded VM
+presented in PAIP [ref], SLip offers an impressive feature set, which
+includes the following and more:
+
+\begin{itemize}
+  \item Self-hosting compiler
+  \item \texttt{TAGBODY}, \texttt{THROW}, \texttt{CATCH}, \texttt{BLOCK}, \texttt{RETURN}, \texttt{UNWIND-PROTECT}
+  \item Foreign Function Interface (FFI) to JavaScript
+  \item Tail-call optimization
+  \item Green threads
+  \item Package system
+  \item TinyCLOS [ref]
+  \item Condition system includes \texttt{HANDLER-CASE} and \texttt{HANDLER-BIND}
+  \item GNU Emacs-like browser-based editor and interactive development environment
+\end{itemize}
+
+Because of interpretation overhead, performance relative to JavaScript
+is necessarily worse.
+
+Generated code is also larger than comparable JavaScript code, so
+applications take longer for users to download than JavaScript
+equivalents.
+
+FASLs can be created that represent Lisp as a series of VM
+instructions encoded as JavaScript function calls. These are faster to
+load in the browser than Lisp source code because the browser uses its
+native parser to load them.
+
+The compiler features a peephole optimizer based on the one in
+PAIP. There is no way to tree-shake the Lisp image or to produce
+standalone JavaScript executable that a static global optimizer such
+as Google Closure could work with.
+
+These performance and code-size limitations render SLip impractical
+for most types of industrial SPA.
+
 \subsection{JSCL}
 
 \subsection{ClojureScript}