git » jacl.git » commit 1147266

paper

author Alan Dipert
2020-02-11 06:44:19 UTC
committer Alan Dipert
2020-02-11 06:44:19 UTC
parent 25af513cd733cf10947e9a387d56f3a1e8a25f9c

paper

paper/jacl-els-2020.tex +55 -5

diff --git a/paper/jacl-els-2020.tex b/paper/jacl-els-2020.tex
index 314d8fa..fbe6d17 100644
--- a/paper/jacl-els-2020.tex
+++ b/paper/jacl-els-2020.tex
@@ -182,7 +182,8 @@ available to Parenscript programs.
 % 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
+system to date, although it intentionally diverges from Common Lisp in
+some respects. Based originally on the compiler and bytecoded VM
 presented in PAIP [ref], SLip offers an impressive feature set, which
 includes the following and more:
 
@@ -211,15 +212,64 @@ 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.
+PAIP. There is no way to tree-shake the Lisp image given an
+entrypoint, or to otherwise produce standalone JavaScript executable
+that a static whole-program optimizer such as Google Closure could
+work with.
 
 These performance and code-size limitations render SLip impractical
-for most types of industrial SPA.
+for the type of of industrial SPA development JACL is designed to
+facilitate.
 
 \subsection{JSCL}
 
+Of existing Common Lisps, JSCL is the one aligned most closely with
+the JACL project goal. Its features include the following:
+
+\begin{itemize}
+  \item Self-hosting compiler and REPL
+  \item \texttt{TAGBODY}, \texttt{THROW}, \texttt{CATCH}, \texttt{BLOCK}, \texttt{RETURN}, \texttt{UNWIND-PROTECT}
+  \item Tight integration with JavaScript
+  \item Multiple values
+  \item \texttt{SETF} places
+  \item \texttt{CLOS}
+\end{itemize}
+
+JSCL's support for JavaScript interoperation consists of the following
+conventions and facilities:
+
+\begin{itemize}
+  \item Unboxed numbers: JSCL fixnums and flonums both map to
+    JavaScript's native \texttt{number} type. This allows for numeric
+    performance competitive with JavaScript.
+  \item Functions are JavaScript functions: JSCL functions compile to
+    concrete JavaScript functions that may be invoked from JavaScript
+    without any special calling convention.
+  \item The \texttt{\#\textbackslash j} pseudo-symbol syntax which I will
+    elaborate on below.
+\end{itemize}
+
+The JSCL reader parses tokens such as \texttt{\#\textbackslash
+  j:window:console:log} as segmented references to hierarchical
+objects in JavaScript's global environment.
+
+In a value context, references evaluate to the referenced JavaScript
+object.  \texttt{\#\textbackslash j:window:console:log} evaluates to
+the same object that the JavaScript expression
+\texttt{window.console.log} does.
+
+In function position of operation forms --- as in
+\texttt{(\#\textbackslash j:window:console:log $"$hello$"$)} ---
+references are taken as the name of a foreign function to
+call. Arguments are coerced from Lisp to JavaScript types
+automatically and applied to the named foreign function. In this
+example, the Lisp string \texttt{$"$hello$"$} is converted to a
+JavaScript string before being passed to the function
+\texttt{window.console.log} for display in the JavaScript console.
+
+TODO Problems with JSCL interop
+TODO Problems with JSCL compiler organization
+
 \subsection{ClojureScript}
 
 %% \subsection{Template Styles}