4 ms·

The use of JS as an object code seems to be a big trend lately. This makes me wonder: (1) How suitable is JS for use as an object code? (2) Is this trend take

The use of JS as an object code seems to be a big trend lately. This makes me wonder: (1) How suitable is JS for use as an object code? (2) Is this trend taken into account by those designing the future of JS?

olavk 17y ago
(1) Depends on how different the source language is from the semantics of JS. JS is a high-level language and doesn't have e.g. goto which would make it easy to implement different execution models. If you don't want to create your own interpreter in JS (which would be an alternative to code generation), you have to be manage with functions (and exceptions). If the source language require more powerful constructs like goto or continuations, you are out of luck. (Theoretically you could gain some power by compiling to a continuation-passing style, but since JS engines doesnt have TCO, I dont think this would work in reality. The scoping rules combined with the distinction between expressions and statements means that it is harder to generate composable snippets. For example you cannot just generate a small "context free" code snippet with a local variable - the scope of a variable is always the function, so you need either to mangle the name to create a unique variable, or create an inline function and call it - but that changes the semantics of return, which again is a hindrance to composability. I would definitely prefer something like scheme as a compilation target, but it could be a lot worse. Imagine compiling to VBScript :-) For my particular project which compiles ES5/Harmony to JavaScript it works quite well, but those languages are based on JavaScript anyway, so that is almost cheating. (2) AFAIK the working group are a aware of the interest in JS a compilation target, but are not at the time considering adding features specifically to make it more suitable for that purpose.
BigZaphod 17y ago
I can't answer either of these very well myself, (although for #1 I speculate that it's prototypical nature makes it easier to target than a class-based language might be), but I think it's primarily targeted by language experimenters because it's incredibly ubiquitous and easy to demo to others (there's nothing new to install) and the coming generation of JS engines are finally using a lot of cutting edge techniques to drastically improve performance which should make their work more practical in the near future.
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 ago
    I 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.
daeken 17y ago
I can't speak to the second point, but to respond to the first: it's very well suited. I've built two primary compiler projects targeting JS, a Python->JS compiler and a 6502 emulator that dynarec's to JS. Both were easy to build and its flexible nature made everything work out very well. I dislike writing JS myself (just don't dig the syntax), but writing compilers backending to it works out quite well.
s3graham 17y ago
I have to disagree with the other commenters as to its suitability as general object code. I find it too high-level, with insufficient control over the lower-level details. For Skulpt (my Python-in-JS implementation) it works "ok" because JS and Python are similar in some respects, so some things map pretty well. But, for other things, like implementing longs (aka bigint), or implementing exceptions and attribute lookup faithfully to Python's semantics, it requires overhead that I consider unnecessary. Control structures from more flexible languages would require extensive hoop-jumping too. Really, JVM-in-browser was the "right" solution, but the implementation of that is obviously horrible and impractical. Not sure about #2, I guess it's a chicken-and-egg problem. With Google compiling from Java there should be some motivation to improve that use-case.

olavk 17y ago

(1) Depends on how different the source language is from the semantics of JS. JS is a high-level language and doesn't have e.g. goto which would make it easy to implement different execution models. If you don't want to create your own interpreter in JS (which would be an alternative to code generation), you have to be manage with functions (and exceptions). If the source language require more powerful constructs like goto or continuations, you are out of luck. (Theoretically you could gain some power by compiling to a continuation-passing style, but since JS engines doesnt have TCO, I dont think this would work in reality. The scoping rules combined with the distinction between expressions and statements means that it is harder to generate composable snippets. For example you cannot just generate a small "context free" code snippet with a local variable - the scope of a variable is always the function, so you need either to mangle the name to create a unique variable, or create an inline function and call it - but that changes the semantics of return, which again is a hindrance to composability. I would definitely prefer something like scheme as a compilation target, but it could be a lot worse. Imagine compiling to VBScript :-) For my particular project which compiles ES5/Harmony to JavaScript it works quite well, but those languages are based on JavaScript anyway, so that is almost cheating. (2) AFAIK the working group are a aware of the interest in JS a compilation target, but are not at the time considering adding features specifically to make it more suitable for that purpose.

BigZaphod 17y ago

I can't answer either of these very well myself, (although for #1 I speculate that it's prototypical nature makes it easier to target than a class-based language might be), but I think it's primarily targeted by language experimenters because it's incredibly ubiquitous and easy to demo to others (there's nothing new to install) and the coming generation of JS engines are finally using a lot of cutting edge techniques to drastically improve performance which should make their work more practical in the near future.

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 ago
  I 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.

daeken 17y ago

I can't speak to the second point, but to respond to the first: it's very well suited. I've built two primary compiler projects targeting JS, a Python->JS compiler and a 6502 emulator that dynarec's to JS. Both were easy to build and its flexible nature made everything work out very well. I dislike writing JS myself (just don't dig the syntax), but writing compilers backending to it works out quite well.

s3graham 17y ago

I have to disagree with the other commenters as to its suitability as general object code. I find it too high-level, with insufficient control over the lower-level details. For Skulpt (my Python-in-JS implementation) it works "ok" because JS and Python are similar in some respects, so some things map pretty well. But, for other things, like implementing longs (aka bigint), or implementing exceptions and attribute lookup faithfully to Python's semantics, it requires overhead that I consider unnecessary. Control structures from more flexible languages would require extensive hoop-jumping too. Really, JVM-in-browser was the "right" solution, but the implementation of that is obviously horrible and impractical. Not sure about #2, I guess it's a chicken-and-egg problem. With Google compiling from Java there should be some motivation to improve that use-case.