Is it technically possible to write a JS interpreter using Lisp macro readers, in the browser?

Question

Using macros readers, it's possible to interpret JavaScript, and have it compiled just like normal Common Lisp code. Hence getting the benefits of Lisp implementations, notably their performance. Which would mean having native performance in the browser, without cheating.

Would it be technically possible to build this for the browser? I'm mainly worried about the DOM bindings.

Answer 1

Sorry, but your assumption is wrong. Lisp is nice and all, but it isn't magic dynamic performance pixie dust.

Compiling/running something that looks sort of like basic JavaScript is one thing. But it is not what is needed.

Add in what is necessary to have said JavaScript have variables that autoconvert between integer, floating point, and string representations according to the spec. Add in the variable lookup method that JavaScript uses. (Variables are looked up in a series of scopes, starting with the current function call.) Add in the object model that JavaScript uses. Continue through the spec, and you will keep on making things slower and slower.

Once you're done, even though you started with Lisp, you've simply got another implementation of a JavaScript runtime that is slow for all the reasons that any other is. It could be faster or slower than existing implementations. Given the optimization effort that has gone into those implementations, it likely will be slower by a wide margin.

At that point, figuring out whether to finish writing a browser in Lisp, or whether to load Lisp into a browser and apply the right JavaScript hooks is up to you. But your performance assumptions are wrong.

Now looking at this, you could be tempted to say that it would be nice to create a new language that can be dynamic and performs better. It would be, but there is a chicken and egg problem. Unless all browsers have it, nobody will use it. Unless people use it, browsers won't write it. This is solvable, for instance look at HTML5 Canvas. But it seems easier to solve if it is targeted at a known pain point, see HTML5 Canvas. Ripping out all of JavaScript for something else does not seem to be an easy thing to do. (Microsoft tried back at the dawn of the web age. When was the last time you saw VBScript in the wild?)

Answer 2

Common Lisp is not the fastest in terms of execution speed when it comes to implementation of other programming languages by compiling it to Common Lisp or even interpreting it in Common Lisp.

Even Common Lisp has basically three different speed ranges:

• the normal Lisp language. It can be compiled efficiently, but there are inherent things which makes it less fast than C and other low-level languages. For example it needs a lot of runtime checks and runtime decisions.

• a low-level Lisp language. This can be compiled to very efficient code. But here we need and exploit performance hints, type declarations, type inference, code inlining and more.

• a high-level object system (CLOS), which is hard to compile to efficient code

But Common Lisp is still used to implement languages. Sometimes for research and exploration.

For example there was an implementation of Javascript in Common Lisp. It was written by Netscape to explore Javascript semantics:

http://mxr.mozilla.org/mozilla/source/js2/semantics/

But as you can see that implementation is not simple and no, 'reader macros' are not of much help.