git » jacl.git » commit 2ba4d8a

diff --git a/paper/jacl-els-2020.tex b/paper/jacl-els-2020.tex
index 3215a6c..e35f1ed 100644
--- a/paper/jacl-els-2020.tex
+++ b/paper/jacl-els-2020.tex
@@ -131,83 +131,152 @@
 
 \section{Introduction}
 
-The demand for SPAs in the past decade has continued to
-grow. Stakeholders and users continue to expect higher and higher
-degrees of sophistication and performance from Web applications.
+The demand for SPAs in the past decade has only grown. Users and
+stakeholders continue to expect higher and higher degrees of scale and
+sophistication from SPA implementors.
 
-To satisfy these rising expectations, Web browser platform
-capabilities have advanced considerably. Beyond drastic improvements
-to JavaScript runtime and layout engine performance, browsers have
-also accumulated APIs for interacting with webcams and audio devices,
-sending and receiving low-latency data over WebSockets, obtaining
-location data, accessing the host filesystem, and more.
+SPA implementors have responded by creating a widening variety of
+special-purpose frameworks and programming languages informed by
+large-scale development experience. Each of these tools promotes one
+or more paradigms, application archictures, or workflows, and claim
+some advantage relative to the status quo.
 
-The growing set of demands and platform capabilities, combined with
-the inherent limitations of the Web browser's security model, pose a unique
-set of challenges to today's SPA implementors.
+This paper presents one new such tool, JACL. However, as an
+implementation of an extended subset of Common Lisp (CL), JACL is
+informed not just by contemporary experience, but also by the sum of
+experience with Lisp since 1957 and through to its eventual
+specification as Common Lisp in 1994.
 
+CL was designed for cross-platform compatibility and its package
+system does not require access to a file system. Consequently, despite
+various limitations imposed by the browser's security model, JACL can
+support a compelling --- albeit degraded --- interactive development
+experience.
 
+CL was designed for efficient implementation, and so JACL can be
+efficient. JACL code compiles nearly directly to JavaScript (JS). Very
+few compiler optimizations are necessary for the performance of JACL
+code to compare favorably to similar code written in other
+compile-to-JS languages.
 
+Finally, CL is easily extended, and so JACL can offer fluent access to
+the JavaScript platform, browser APIs, and APIs provided by 3rd party
+JavaScript libraries.
 
+Limitations inherent in the browser platform, and a conscious decision
+not to attempt to mitigate them for performance reasons, mean that
+JACL will never be a complete implementation of CL. However, it is
+hoped that despite its incompleteness, and after planned work is
+completed, JACL may offer a satisfying Lisp development experience and
+serve as ``building material'' for a new generation SPA implementation
+tools and techniques.
 
-To satisfy these rising expectations, the stack of network computing
-standards, infrastructure, and technology supporting the SPA concept
-have all advanced considerably in the same period. HTTP/2, pervasive
-CDNs, JavaScript runtimes, and layout engines are a few notable
-examples.
 
-As the technology fabric supporting SPAs has moved forward, so too
-have the practices of application implementors.
 
-In the past decade, SPAs have grown considerably in ambition and
-complexity, and languages for SPA development that compile to
-JavaScript --- but claim some advantage relative to it, often with
-regard to large-scale development --- have increased in number and
-popularity.
 
-For the most part, these languages imply a development workflow
-characterized by alternating batch compilation with whole-program
-reloading, and an application architecture oriented around the
-affordances of static type-checking. Dart, TypeScript
-\cite{Somasegar12}, Elm, and Flow are some well-known examples.
 
 
 
-
-
-This paper presents JACL. As a Lisp, JACL promotes a
-compilation model oriented around the manipulation of a Lisp image. 
-
-a
-workflow oriented around the manipulation of a Lisp image, and as a
-Lisp, implies much less about application architecture while
-supporting interactive development and bottom-up design.
-
-\subsection{Tool Development}
-
-First, the batch compilation workflow impedes the production of
-development tools for combating complexity on a per-application
-basis. A compiler toolchain such as Grunt or Webpack must first be
-installed on the development machine, and such toolchains typically
-require extensive configuration and maintenance. This configuration
-activity, while a prerequisite, is orthogonal to SPA development in
-the sense that it's effected in a language and environment disparate
-from that of the SPA. For example, the toolchain platform is usually
-Node.js, while the SPA platform is that of the Web browser. Although
-Node.js and the Web browser are both programmed in JavaScript,
-significant differences between these platforms are likely to
-discourage per-application tool development.
-
-Development tools are usually created organically as part of the
-development process. The harder such tools are to create, the more
-application complexity developers must regularly inure themselves to.
-
-\subsection{Interactive Development}
-
-Second, static type-checking impedes interactive development, which is
-a well-known technique for rapidly producing high-quality
-software. Compilers that perform static type-checking are necessarily
-slower than those that do not, which increases ``cycle time.'' 
+%% Owing to the semantic similarities of CL and JavaScript, and even to the JavaScript to
+%% which it nearly directly compiles. CL
+%% 
+%% 
+%% 
+%% 
+%% 
+%% Where browser implementors are 
+%% The primary means by which implementors have risen to meet this increasing demand is through the development of special-purpose languages and frameworks.
+%% 
+%% 
+%% High-performance industrial SPA development has always been challenging, owing to idiosyncrasies of the browser platform. These include the browser security model, subtle differences between 
+%% 
+%% In addition to the traditional constraints associated with SPA development, such as the browser's security model, subtle differences between browsers, and idiosyncrasies of the JavaScript language, implementors are increasingly faced
+%% 
+%% Constraints inherent to the browser platform, such as the browser security model and the sensitivity of SPAs to network conditions, have always 
+%% 
+%% The browser platform on which SPAs are built has evolved considerably
+%% in the same period. JavaScript runtime and layout engine performance
+%% have both improved dramatically. Browsers have accumulated APIs for
+%% interacting with video and audio devices, sending and receiving data
+%% over WebSockets, collecting sensor data, location data, and more.
+%% 
+%% The inhe
+%% 
+%% Between stakeholder expectations, 
+%% 
+%% To satisfy these rising expectations, Web browser platform
+%% capabilities have advanced considerably. Beyond drastic improvements
+%% to JavaScript runtime and layout engine performance, browsers have
+%% also accumulated APIs for interacting with webcams and audio devices,
+%% sending and receiving low-latency data over WebSockets, obtaining
+%% location data, accessing the host filesystem, and more.
+%% 
+%% The growing set of demands and platform capabilities, combined with
+%% the inherent limitations of the Web browser's security model, pose a unique
+%% set of challenges to today's SPA implementors.
+%% 
+%% 
+%% 
+%% 
+%% 
+%% To satisfy these rising expectations, the stack of network computing
+%% standards, infrastructure, and technology supporting the SPA concept
+%% have all advanced considerably in the same period. HTTP/2, pervasive
+%% CDNs, JavaScript runtimes, and layout engines are a few notable
+%% examples.
+%% 
+%% As the technology fabric supporting SPAs has moved forward, so too
+%% have the practices of application implementors.
+%% 
+%% In the past decade, SPAs have grown considerably in ambition and
+%% complexity, and languages for SPA development that compile to
+%% JavaScript --- but claim some advantage relative to it, often with
+%% regard to large-scale development --- have increased in number and
+%% popularity.
+%% 
+%% For the most part, these languages imply a development workflow
+%% characterized by alternating batch compilation with whole-program
+%% reloading, and an application architecture oriented around the
+%% affordances of static type-checking. Dart, TypeScript
+%% \cite{Somasegar12}, Elm, and Flow are some well-known examples.
+%% 
+%% 
+%% 
+%% 
+%% 
+%% This paper presents JACL. As a Lisp, JACL promotes a
+%% compilation model oriented around the manipulation of a Lisp image. 
+%% 
+%% a
+%% workflow oriented around the manipulation of a Lisp image, and as a
+%% Lisp, implies much less about application architecture while
+%% supporting interactive development and bottom-up design.
+%% 
+%% \subsection{Tool Development}
+%% 
+%% First, the batch compilation workflow impedes the production of
+%% development tools for combating complexity on a per-application
+%% basis. A compiler toolchain such as Grunt or Webpack must first be
+%% installed on the development machine, and such toolchains typically
+%% require extensive configuration and maintenance. This configuration
+%% activity, while a prerequisite, is orthogonal to SPA development in
+%% the sense that it's effected in a language and environment disparate
+%% from that of the SPA. For example, the toolchain platform is usually
+%% Node.js, while the SPA platform is that of the Web browser. Although
+%% Node.js and the Web browser are both programmed in JavaScript,
+%% significant differences between these platforms are likely to
+%% discourage per-application tool development.
+%% 
+%% Development tools are usually created organically as part of the
+%% development process. The harder such tools are to create, the more
+%% application complexity developers must regularly inure themselves to.
+%% 
+%% \subsection{Interactive Development}
+%% 
+%% Second, static type-checking impedes interactive development, which is
+%% a well-known technique for rapidly producing high-quality
+%% software. Compilers that perform static type-checking are necessarily
+%% slower than those that do not, which increases ``cycle time.''