3 ms·
How suitable is JS for use as an object code? Highly. I think it's a much nicer language to compile to than to write by hand (although JS is a pretty good lang
by gruseom 17y ago
How suitable is JS for use as an object code?
Highly. I think it's a much nicer language to compile to than to write by hand (although JS is a pretty good language), especially if you want to use a very high-level language and have your code run in a web browser. We compile to JS from Common Lisp using a set of macros built on top of the excellent Parenscript library. We've built things up incrementally to the point that we're now able to write most of our app in a subset of Common Lisp that compiles to efficient JS. The other day I took some Lisp code I wrote a year ago and generated JS from it without having to change it. That's the first time that's happened. (We'll probably open-source this eventually as a layer on top of Parenscript.)
A big advantage of this approach over JS libraries is that you can emit quite low-level JS, so you don't have to pay for all that abstraction at runtime.
Having said the above, I'll partly take it back. JS isn't completely object code in the sense that you can generate it and forget about it. You need to be able to debug it in the web browser, and that means you need to be able to read it. In that sense, it's not really object code.
- Hexstream 17y ago"Having said the above, I'll partly take it back. JS isn't completely object code in the sense that you can generate it and forget about it. You need to be able to debug it in the web browser, and that means you need to be able to read it. In that sense, it's not really object code." I'm pretty sure it must be possible to 1. preserve the "semantic trace" of compilation from high-level Lisp to low-level JS and then 2. write a high-level debugger that, given a piece of object-code that went wrong, points to the high-level code that generated it. A complete solution might be intractable but even a partial solution could greatly help debugging.
- olavk 17y agoI compile from ECMAScript 4 to JS, and what I do is create a separate mapping file, where line/char pos for every token in the generated file is mapped to file/line/char in the source. When the JS engine throws a runtime error it typically (depending on the engine) includes line/char pos for the point of error. A wrapper then extract line/char from the error message, finds the corresponding position in the original source, and displays that also. This greatly helps debugging runtime errors. It is not perfect, since some engines (e.g. Rhino) doesn't include position for runtime errors.
- gruseom 17y ago(I was offline for a few days, but want to reply anyway.) My partner and I were just discussing this the other day: write a high-level debugger that, given a piece of object-code that went wrong, points to the high-level code that generated it. There are a lot of interesting tools one could build in this space. For example, a Slime-style REPL that provides Firebug-like access to JS in the browser, but via Parenscript forms, would be a really nice addition. As for your debugger suggestion, I would love to have such a thing. But first, I'd settle for having such a thing in the Lisp environment alone - it's my biggest pet peeve about CL that the debugger situation is so bad.