Different ways to run Scheme in the browser
Lassi Kortela 29 Dec 2020 18:29 UTC
> I’m not sure what is the meaning of the labels “Interpreter” and “Compiler”.
Interpreter = REPL that runs in the browser, e.g. gsi via emscripten
Compiler = you can run a compiler on your computer, to pre-compile a
Scheme program to files that can be uploaded on a web server and then
run in the browser, e.g. gsc's JS backend
> In any case Gambit can be used in various ways to allow running Scheme code in the browser:
>
> 1) Build the normal system (a bunch of .c/.h files) to JS using emscripten. This will give a JS version of the Gambit interpreter. I would expect this approach to work in principle for any Scheme system that is implemented in portable C code (“in principle” because some implementations of Scheme use non-portable tricks that won’t work on emscripten). So perhaps this should be a category in itself in your table… i.e. “can be compiled to JS using emscripten”.
Excellent advice. Emscripten would probably be better than Docker for
running traditional Scheme implementations in the browser - at least the
ones that aren't huge.
Can programs compiled via Emscripten load files from the server at
runtime in the browser? That way, if an implementation comes with a big
standard library written in Scheme, that library could be left out of
the executable and loaded on demand from the server via normal HTTP GET
requests.
> 2) Use Gambit’s JavaScript backend to compile the Gambit runtime library (which includes the REPL). This gives a Gambit interpreter in JS (and no C code is involved in the pipeline).
Very interesting. So the runtime library includes the interpreter, which
includes (eval ...), and eval can be compiled directly into JavaScript
and it keeps working. Does this eval use a modified version of the
closure compiler approach you invented with Lapalme back in the day?
> 3) Use the Gambit compiler’s JavaScript backend (i.e. “gsc -target js -exe prog.scm”) to compile Scheme programs to JS thus avoiding the use of an interpreter at run time and (possibly) faster and more compact web apps.
This is probably what most people would want for production, once they
have ironed out the bugs from their program.