4 ms·

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 u

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'

cantankerous 13y ago
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 :-).
homeomorphic 13y ago
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.
- fosap 13y ago
  It has more backends: GCC style C annnnddddd.... Javascript.
  - carterschonwald 13y ago
    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. :-)
spion 13y ago
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/sourcemaps/ http://www.html5rocks.com/en/tutorials/developertools/source...
- tieTYT 13y ago
  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 :)
  - davesque 13y ago
    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.
munificent 13y ago
> 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?
- marshray 13y ago
  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.
- foobarbazqux 13y ago
  asm.js is designed for static compilation, there's no magic.

cantankerous 13y ago

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 :-).

homeomorphic 13y ago

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.

fosap 13y ago
It has more backends: GCC style C annnnddddd.... Javascript.
- carterschonwald 13y ago
  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. :-)

spion 13y ago

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/sourcemaps/ http://www.html5rocks.com/en/tutorials/developertools/source...

tieTYT 13y ago
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 :)
- davesque 13y ago
  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.

munificent 13y ago

> 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?

marshray 13y ago
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.
foobarbazqux 13y ago
asm.js is designed for static compilation, there's no magic.