Compiling Lisp to JavaScript in 350 Lines of Haskell

Converting “lisp” to JavaScript in the sense of this article is basically trivial (but then it was done in only 350 lines of Haskell).

Compiling, say, Common Lisp to JavaScript is hard. There are “easy” steps (in the sense that they can be ignored or done a stupid way at first) like dealing with numbers, namespaces, packages, (I.e. the symbol foo can name a function and a variable, amongst other things, and the symbols #:foo and #:foo are not equal).

There are the “boring” steps like doing argument parsing (and harder is working out how to make it efficient)

There are the hard steps like working out how to compile lexical goto and return-from, eval-when

There are the very hard steps necessary for macros like having to reimplement a macroexpander (for macrolet and friends) and then realising that this is insufficient as one also needs to implement environment and such (but this can be done by a macro to slightly modify macros, assuming that this compiler is also implemented in Common Lisp). But this still is insufficient. Consider the following legal Common Lisp:

  (defun make-adder (number)
    (lambda (x) (+ x number))
  (defmacro macro-+ (a b)
    `(funcall ,(make-adder a) ,b))
  (defun foo (y) (macro-+ 3 y))

So the body of foo expands into:

  (funcall #<lambda ...> y)

And one has no way to compile this host-system function to JavaScript and hence to expand macros one needs to be able to interpret Common Lisp and be able to convert any object into JavaScript source code (and keep in mind that the source code needs to ensure that what we’re identical in the CL are identical when the JS is compiled, and that closed-over variables are also properly dealt with in the sense that if two different functions close over the same variable in CL then they need to be compiled into JS functions that close over the same variable, or at least behave the same as the CL functions.

Having to interpret does at least solve problems like having numbers behave the same way in macros as at runtime.

And then there is CLOS which is a bit of a pain to bootstrap (and must be bootstrapped twice of course).

To compile CL to JS one essentially needs three CL compiler (backends), one for macros in the first compile, one for compiling to JS and one for compiling and linking in the code that is compiled at runtime in the JS VM.

Cool stuff. I wrote a simple Hindley-Milner type language interpreter in Haskell inspired by Haskell a while back. Consider using Parsec as a parser combinator library.

next reading: common lisp to pascal using a pretty printer https://www.reddit.com/r/lisp/comments/1totwx/some_useful_li...

350 lines of Haskell.