author | Alan Dipert
<alan@dipert.org> 2020-02-20 23:37:38 UTC |
committer | Alan Dipert
<alan@dipert.org> 2020-02-20 23:37:38 UTC |
parent | ea2cca0f34b39352f1220ddc076b2f7c74ec8c93 |
paper/jacl-els-2020.tex | +4 | -6 |
diff --git a/paper/jacl-els-2020.tex b/paper/jacl-els-2020.tex index 9906216..1225d28 100644 --- a/paper/jacl-els-2020.tex +++ b/paper/jacl-els-2020.tex @@ -404,15 +404,13 @@ loading source files in dependency order. An advantage of the reader approach taken by JACL with respect to the implementation of \texttt{jacl-client} is that the REPL client is completely ignorant of Lisp syntax and semantics. \texttt{jacl-client} -merely buffers and sends characters over the WebSocket and into the -Lisp system, and displays characters output from Lisp. While -\texttt{jacl-client} presents a synchronous input/output interface, it -is actually the frontend for bidirectional asynchronous data transfer. +merely transfers characters between the host machine and the Lisp +system and so is \emph{not} a pre-reader. There are various obvious way the JACL REPL experience could be improved. For example, \texttt{jacl-repl} is currently an -R\cite{Rstats} script requiring an R installation and installation of -the \texttt{chromote}\cite{Rchromote} package. A standalone binary +R\cite{Rstats} script requiring an R installation and the +\texttt{chromote}\cite{Rchromote} package. A standalone binary executable is imagined in the future in order to make it easier for developers to start working on JACL projects. Additionally, JACL has yet to define a printer for its native types, or an extensible print