Almost certainly can't. The closest you can get is using clicc or ECL or something similar to generate C code, and then compile that with emscripten.
This invokes llvm at runtime, and AFAIK emscripten isn't ported to emscripten.
FWIW, I've tried other lisps under emscripten:
Most lisps generate machine code, store them in RAM, and then execute that RAM. This is not possible under emscripten.
Clisp is a good candidate, since it's byte-code interpreted rather than generating machine code, but clisp makes so many assumptions about how the machine works (in particular it strongly wants a C style stack and does manual stack-pointer manipulation). I actually got fairly far into the bootstrap process under emscripten, but the minimal lisp interpreter it compiles generated bizarre errors.
I disagree. Clasp could do this because it compiles Common Lisp to LLVM-IR bitcode files (using COMPILE-FILE) as well as directly to native code using LLVM's MCJIT engine (using COMPILE). emscripten (https://github.com/kripken/emscripten) says that it compiles LLVM-IR to JavaScript. I haven't used emscripten, but I believe everything I read on the internet :-) and thus Common Lisp --[Clasp]--> LLVM-IR bitcode files --[emscripten]--> run within browsers.
I'm not an expert in Common Lisp internals, but there are some things that don't look like they could be entirely put in an executable without bringing the compiler and runtime along. I'm not just talking about things like a library that outright uses eval, but the more high-level things like macros that call compiled functions and reader macros.
Then again, you might be able to compile the compiler to LLVM IR -> emscripten -> JavaScript, and use that to compile CL code.
Agreed, but it's more of a "tree-shaking problem" than anything else. Clasp is written in C++ and Common Lisp. Clasp compiles Common Lisp to LLVM-IR and Clang compiles C++ to LLVM-IR. So theoretically you could compile everything to LLVM-IR and feed that to emscripten. Granted, it's going to be a _huge_ LLVM-IR file. Then you shake out the functions and globals that aren't needed. If the compiler isn't needed then it will shake out (or not be compiled in in the first place). The question for me is "what problem does it solve". I assume there are problems that I'm not aware of that it would solve, otherwise why would someone develop emscripten? Common Lisp is a fantastic language that is really underutilized, it's fun and so expressive. I fell in love with Common Lisp three years ago so deeply that I wrote a new Common Lisp to solve my scientific programming challenges while still being able to make use of powerful C++ libraries. I think everyone should use it everywhere - it's awesome.
Sorry to go offtopic but since the you mentioned emscripten I though I'd ask.
Can you explain what emscripten is used for? I'm fully aware of what it does, just not why someone would want to use it. How do you use things like jQuery or access window or document from C and then compile it to js? Or is emscripten specifically for js that doesn't interact with the DOM?
This invokes llvm at runtime, and AFAIK emscripten isn't ported to emscripten.
FWIW, I've tried other lisps under emscripten:
Most lisps generate machine code, store them in RAM, and then execute that RAM. This is not possible under emscripten.
Clisp is a good candidate, since it's byte-code interpreted rather than generating machine code, but clisp makes so many assumptions about how the machine works (in particular it strongly wants a C style stack and does manual stack-pointer manipulation). I actually got fairly far into the bootstrap process under emscripten, but the minimal lisp interpreter it compiles generated bizarre errors.