author | Alan Dipert
<alan@dipert.org> 2020-02-11 06:44:19 UTC |
committer | Alan Dipert
<alan@dipert.org> 2020-02-11 06:44:19 UTC |
parent | 25af513cd733cf10947e9a387d56f3a1e8a25f9c |
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}