Hacker News Reader

Comment by wtbob | Hacker News Reader

This is extremely exciting, particularly if it can be made to work with emscripten. Common Lisp in the browser, here we come!

View on HN

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.

If you can generate standalone bitcode that doesn't ever generate more bitcode at runtime, then yes emscripten becomes a possibility.

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?

http://kripken.github.io/emscripten-site/docs/api_reference/...

http://chadaustin.me/2014/09/connecting-c-and-javascript-on-...

> Common Lisp in the browser, here we come!

You have Parenscript for that: http://common-lisp.net/project/parenscript/

(I haven't used it yer though.)

It works really well. It's a subset of CL that it can compile though so you'll miss out on CLOS, restarts, etc. However the subset does include macros so it's serviceable.

It looks like there is an extension to Parenscript called PSOS[0], which provides conditions/restarts and something similar to CLOS.

[0] https://github.com/gonzojive/paren-psos

unfortunately PSOS does not use the current version of parenscript. It is based on an older and modified version.

I don't see why we couldn't do this. emscripten (https://github.com/kripken/emscripten) says it takes LLVM-IR to JavaScript. The Clasp (Common Lisp) function COMPILE-FILE compiles to LLVM-IR bitcode files. If you have some time and you would like to do this - hit me up with an email - I'd love to make this happen.

You'll probably run into all the same problems other Common Lisps run in to when they try to shake out the compiler from their runtime, namely that often you really do want to create and run new code at runtime (i.e. EVAL but much more often (compile nil '(lambda () ...)). A common example in CL is creating CLOS dispatch functions with specialized parameters to speed up generic dispatch, which I believe most CLOS implementations do at runtime (certainly SBCL/CMUCL's PCL does). You'll wind up needing to include your compiler, Emscripten itself, and all of their dependencies (LLVM libraries?) which will be quite a huge pile of JavaScript. The alternative is to include a CL interpreter but that has obvious speed problems.

ClojureScript already exists, and even if it's not Common Lisp, its still Lisp with homoiconity, macros and what not.

Ok. Anyone can explain what do I get the downvotes for?

I did not downvote you, but I find your suggestion very amusing because it's so casually out of context.

Being Lisp does not make one Lisp family language replacement for other. Language feature list is not sufficient for comparing the similarity of languages. Clojure and CL are very different languages with very different programming styles. You might have suggested Javascript just as easily.

I still don't understand comparing Javascript to Clojurescript in terms of closeness to Common Lisp. Could someone explain what makes CL and Clojure so radically different?

They are about as similar as Python and Ruby. Everything from the names of operators to the stance on mutability, to the more obscure corners (Compiler macros, reader macros, etc).

For a person who played with lot of programming languages, but not many Lisps it makes sense. Thanks.

I didn't downvote you, but I'm honestly not interested in a non-Common Lisp in the browser. I suppose some zealot(s) downvoted you.

https://github.com/davazp/jscl

Reply on news.ycombinator.com