Hacker News Reader

Comment by marshray | Hacker News Reader

Is it just me or does not a week go by without another FP-to-Javascript compiler project?

I love this trend, but I'd really love to see an asm.js target. GHC uses LLVM, which has such a backend, right?

Edit: previously I said 'Clang' instead of 'LLVM'

It's not quite so simple in the case of GHC. The runtime is where the problem is. It's got a lot of special (potentially handwritten/target-specific stuff) that gets baked into Haskell programs (which is why a lot of trivial Haskell program binaries are so big).

I think that the creators of tools like this would consider this an optimization for later iterations. The application/integration of asm.js would be two-fold for them. The (non-trivial) runtime that Haskell uses would need to be rewritten by hand in asm.js and the compiler would need to be reconfigured to emit asm.js.

I want to see asm.js, too. I think these two things create a big bucket of work that the initial creator of the compiler doesn't want to implement up front. I'm a bit interested in contributing to this. Maybe I can learn me some asm.js and see what I can do :-).

Whenever I see a new to-JS compiler, I first check if it supports source maps [1]. If it doesn't, I ignore it (until it does).

edit: okay, I don't always ignore them, but writing code which will need to be maintained is definitely out of the question (anything more complex than tiny toy apps)

[1]: http://www.html5rocks.com/en/tutorials/developertools/source...

I don't think it's as important as you might think (but maybe I'm just naive). I've been developing a game in CoffeeScript for over 2 months and I've yet to need a source map. Every time I get a runtime error, the javascript is easy enough to understand to figure out where I made my error in my CoffeeScript code. And, maybe it's naivety, but I can't imagine having a source map making that feedback loop any faster.

Of course, CoffeeScript is probably way closer to the javascript it generates than Haste and ClojureScript are. That may make all the difference. For the 3rd time now, that may just be my naivety :)

Coffeescript might not be the best example. It strives to be a "symbiotic" language which emphasizes the finer aspects of the host language (Javascript) by introducing special syntax. It tries to avoid constructs which would require any kind of virtual-machinary in order to run. As a result, Javascript code compiled from Coffeescript is pretty easy to follow.

I'm not sure the same could be true for Javascript compiled from a language like Haskell.

GHC doesn't use Clang. It has two backends: native and LLVM. AFAIK there is some work going on to combine the latter with emscripten to get JS output, but apparently it doesn't work for the runtime yet.

It has more backends: GCC style C annnnddddd.... Javascript.

No. the gcc c backend has been deprecated / disabled for nearly half a decade. It has ceased to be, it is no more, it is dead. :-)

> I love this trend, but I'd really love to see an asm.js target.

Why? Is "asm.js" just a mnemonic for "magically fast", or is there something specific you think would be gained by not using the full target language JS as a compiler target?

asm.js is designed for static compilation, there's no magic.

I just really like this idea of standardizing on a low-level subset of Js for use by intermediate language representations such as this. So in other words, the former.

Reply on news.ycombinator.com