author | Alan Dipert
<alan@dipert.org> 2020-02-13 04:06:00 UTC |
committer | Alan Dipert
<alan@dipert.org> 2020-02-13 04:06:00 UTC |
parent | 9c1b0df214a7f2be90a1705c4279ebf5c627969c |
paper/jacl-els-2020.tex | +6 | -7 |
diff --git a/paper/jacl-els-2020.tex b/paper/jacl-els-2020.tex index fc3a287..823d1bd 100644 --- a/paper/jacl-els-2020.tex +++ b/paper/jacl-els-2020.tex @@ -231,15 +231,14 @@ what's capable of being read by the underlying, full-featured synchronous reader. Incidentally, SLip's reader is also synchronous, and its Emacs clone, -ymacs, also includes a pre-reader as part of its Lisp interaction +Ymacs, also includes a pre-reader as part of its Lisp interaction mode. -Because JSCL includes no demonstration of embedding the REPL in an -application, and because JSCL itself is compiled in batch through a -synchronous process, the limitations of the pre-reader appear not to -encumbered those who have used JSCL to date. However, the lack of a -full-fledged asynchronous, embeddable reader severely limits JSCL as -an interactive Lisp development environment. +JSCL and SLip demonstrate that when the underlying reader facility is +synchronous, a REPL cannot effectively be made available at run-time +because of the asynchrony of input events in JavaScript. In the best +case, the reader is only partially available through an a pre-reader +that accumulates datums asynchronously. \subsubsection{Compiler organization}