| author | Alan Dipert
<alan@dipert.org> 2020-02-07 07:01:18 UTC |
| committer | Alan Dipert
<alan@dipert.org> 2020-02-07 07:01:18 UTC |
| parent | 0b166bde980669c71844b202f5b5303724e4a715 |
| paper/jacl-els-2020.tex | +27 | -321 |
diff --git a/paper/jacl-els-2020.tex b/paper/jacl-els-2020.tex index ea79dfe..3708a58 100644 --- a/paper/jacl-els-2020.tex +++ b/paper/jacl-els-2020.tex @@ -40,11 +40,8 @@ \author{Alan Dipert} \email{alan@dipert.org} -%% -%% The abstract is a short summary of the work to be presented in the -%% article. \begin{abstract} - Single-page Web Applications (SPAs) remain a popular technique for + Single-page Web Applications (SPAs) are 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 @@ -56,43 +53,6 @@ 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 ease SPA development by facilitating the use of CL. - - %% \begin{enumerate} - %% \item Support efficient compilation and application delivery - %% \item Integrate tightly with the Web browser platform, and - %% \item Promote an interactive, incremental, and bottom-up approach - %% to development in the Lisp tradition - %% \end{enumerate} - - %%project goals are to: - - %%\begin{itemize} - %% \item Promote an \textit{interactive}, image-based development workflow supporting incremental, bottom-up development, in the Lisp tradition - %% \item Integrate tightly with the Web browser platform - %% \item Produce executables competitive in size and speed with those produced by other popular compiled-to-JavaScript languages - %%\end{itemize} - - -%%In response to the technical demands of SPAs, JavaScript and the Web -%%browser platform have evolved considerably in the past decade. -%% -%% -%% Google's GMail Web application is a well-known example. In response -%% to the technical demands of SPAs, JavaScript and the Web browser -%% platform have evolved considerably in the past decade. In the same -%% period, SPAs grew in complexity and ambition, and languages that -%% compile to JavaScript --- but claim some advantage relative to it, -%% often with regard to the management of complexity --- have increased -%% in number and popularity. With a few exceptions, these languages -%% promote application architectures oriented around the affordances of -%% compile-time type systems, and a development workflow characterized -%% by alternating batch compilation with whole-program reloading. In -%% this paper, I introduce a new, Web browser-based implementation of -%% an extended subset of Common Lisp called Javascript-Assisted Common -%% Lisp or \textbf{JACL}. JACL is an incomplete but ongoing effort to -%% promote an interactive workflow that improves the efficiency of SPA -%% development without compromising on the size or speed of -%% deliverables, relative to contemporary alternatives. \end{abstract} %% @@ -164,16 +124,35 @@ high-performance applications. The primary goal of the JACL project is to ease the task of SPA development by applying the design of CL to the challenges faced by -implementors. JACL is envisioned as the means to that goal, and as a -practical, modern implementation that integrates tightly with the Web -browser platform. +implementors. JACL is envisioned as the means to that goal, and to +have at least the following additional affordances: + +\begin{itemize} + \item Support for a compelling interactive development experience in + the Lisp tradition. + \item Ability to load source code from the host filesystem. + \item Fluent interoperation with JavaScript. + \item Ability to produce competitively fast and small deliverable + executables. +\end{itemize} In this paper, I will describe JACL's design and the current state of -its implementation. Then, I will outline remaining work, including -tentative features to support optimized application delivery. +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 +by a JavaScript program. The vast majority of these were created for +educational purposes. In order to focus my comparison, I will only +discuss Lisps that meet any of the following criteria: + +\begin{itemize} + \item They implement a significant subset of Common Lisp. + \item They approach the challenges of large-scale development. +\end{itemize} + \subsection{Parenscript} \subsection{SLip} @@ -182,279 +161,6 @@ tentative features to support optimized application delivery. \subsection{ClojureScript} -%% To date, most of the work undertaken in pursuit of this goal has been -%% that which is necessary to support two traditional Lisp workflows: -%% interactive development and application delivery. -%% -%% -%% with respect to current and future support of the interactive -%% development and application delivery workflows. -%% -%% Each of these workflows implies a particular set of implementation -%% capabilities. In this paper, I will outline and rationalize the design -%% of JACL with respect to how -%% -%% previous and contemporary analogues when applicable. Then, I will -%% outline plans for future work. -%% -%% Relative to most contemporary languages that compile to JavaScript, -%% JACL takes a distinctive approach to supporting the interactive -%% development workflow. The JACL reader, compiler and as many ancillary -%% tools as possible are designed to run in the Web browser, in the same -%% execution environment as the application under development. This is an -%% effort to promote the the creation of development tools as natural -%% by-products of the wider application development activity. -%% -%% In contrast to historical residential Lisp systems, JACL does not -%% imply a particular editor, nor does it provide facilities for storing -%% and distributing source code files. Instead, JACL will necessarily -%% rely on at least two categories of tool that must run outside of the -%% Web browser. One is a REPL client for interacting with the JACL system -%% from the command-line, such as fromk -%% -%% -%% -%% -%% -%% This ensures that a full JACL development environment -%% -%% For example, the interactive development workflow implies the -%% availability of a Read Eval Print Loop (REPL) and of a package system -%% that may be queried and dynamically modified. Development also -%% necessarily involves loading source code files from disk. -%% -%% The application delivery workflow implies careful consideration of the -%% runtime system, because in a SPA context applications are downloaded -%% by browsers on demand, and network speeds are not yet universally -%% fast. -%% -%% are best mapped to JavaScript language and runtime features. -%% -%% -%% The designers of CL could not have anticipated the particular -%% idiosyncrasies of JavaScript or of the Web platf -%% -%% -%% -%% -%% -%% -%% -%% Principally, JACL is an effort to overcome the SPA implementation -%% challenges of today by bringing CL's hard-won -%% -%% -%% bring the knowledge CL represents, -%% in the form of its implementation, to bear in a modern setting --- -%% that of SPA implementation in 2020. -%% -%% -%% -%% -%% Fortuitously, they are the same as those -%% faced by contemporary SPA implementors. -%% -%% was designed to help mitigate cetain inherent, timeless -%% challenges that large-scale development on any platform is certain to -%% present. The most direct mitigation proposed by -%% -%% the difficulties inherent in large-scale application development -%% were well known to the designers of CL. -%% -%% -%% The nature of these difficulties is no different in the SPA setting, and so the remedies suggested by CL -%% -%% CL was heavily influenced by many of the same challenges to -%% large-scale application development faced by SPA implementors today. -%% -%% And, while the specific indiosyncrasies of the browser platform would have been impossible for the CL designers to anticipate, -%% -%% -%% -%% . -%% 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. CL's syntactic extensibility also distinguishes -%% JACL as a means to rapidly prototype Domain-Specific Languages (DSLs), -%% such as those that might be designed for composing UIs, dataflow -%% primitives, or for some other special purpose. -%% -%% 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 -%% finished, JACL may offer a satisfying Lisp development experience and -%% serve as ``building material'' for a new generation SPA implementation -%% tools and techniques. - - - - - - - -%% 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.'' - - - -%% Google's GMail Web application is a well-known example. In response -%% to the technical demands of SPAs, JavaScript and the Web browser -%% platform have evolved considerably in the past decade. In the same -%% period, SPAs grew in complexity and ambition, and languages that -%% compile to JavaScript --- but claim some advantage relative to it, -%% often with regard to the management of complexity --- have increased -%% in number and popularity. With a few exceptions, these languages -%% promote application architectures oriented around the affordances of -%% compile-time type systems, and a development workflow characterized -%% by alternating batch compilation with whole-program reloading. In -%% this paper, I introduce a new, Web browser-based implementation of -%% an extended subset of Common Lisp called Javascript-Assisted Common -%% Lisp or \textbf{JACL}. JACL is an incomplete but ongoing effort to -%% promote an interactive workflow that improves the efficiency of SPA -%% development without compromising on the size or speed of -%% deliverables, relative to contemporary alternatives. -%% ACM's consolidated article template, introduced in 2017, provides a -%% consistent \LaTeX\ style for use across ACM publications, and -%% incorporates accessibility and metadata-extraction functionality -%% necessary for future Digital Library endeavors. Numerous ACM and -%% SIG-specific \LaTeX\ templates have been examined, and their unique -%% features incorporated into this single new template. -%% -%% If you are new to publishing with ACM, this document is a valuable -%% guide to the process of preparing your work for publication. If you -%% have published with ACM before, this document provides insight and -%% instruction into more recent changes to the article template. -%% -%% The ``\verb|acmart|'' document class can be used to prepare articles -%% for any ACM publication --- conference or journal, and for any stage -%% of publication, from review to final ``camera-ready'' copy, to the -%% author's own version, with {\itshape very} few changes to the source. -%% -%% \section{Template Overview} -%% As noted in the introduction, the ``\verb|acmart|'' document class can -%% be used to prepare many different kinds of documentation --- a -%% double-blind initial submission of a full-length technical paper, a -%% two-page SIGGRAPH Emerging Technologies abstract, a ``camera-ready'' -%% journal article, a SIGCHI Extended Abstract, and more --- all by -%% selecting the appropriate {\itshape template style} and {\itshape -%% template parameters}. -%% -%% This document will explain the major features of the document -%% class. For further information, the {\itshape \LaTeX\ User's Guide} is -%% available from -%% \url{https://www.acm.org/publications/proceedings-template}. -%% %% \subsection{Template Styles} %% %% The primary parameter given to the ``\verb|acmart|'' document class is @@ -878,8 +584,8 @@ tentative features to support optimized application delivery. %% %% The next two lines define the bibliography style to be used, and %% the bibliography file. -\bibliographystyle{ACM-Reference-Format} -\bibliography{jacl-els-2020} +%% \bibliographystyle{ACM-Reference-Format} +%% \bibliography{jacl-els-2020} %% %% If your work has an appendix, this is the place to put it.