Haste – A Haskell to JS Compiler | Hacker News Reader

Haste – A Haskell to JS Compiler

hackage.haskell.org

64 pointsfreqheist23 comments

Here the discussion on reddit.com/r/haskell:

http://www.reddit.com/r/haskell/comments/1htqi2/announce_has...

That's the place where most intensive discussion on this kind of news usually takes place... (which holds true for this piece of news too)

edit: The reddit discussion contains an well written overview of differences between haste, ghcjs and fay (the 3 main haskell-to-js projects).

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.

It is probably more useful to link to the github page https://github.com/valderman/haste-compiler

Having never used Haskell, I do not know if it would be possible to use it on itself so as to be able to run sample haskell test programs entered by a user on a web page.

Having JS, ARM, and Intel compilers now make Haskell a multi-platform tool of choice among discriminating hackers ;-).

Let's just wait for GHCi support on both JS and ARM.

Just port over the GHC monad and you're golden ;-).

How can it support cabal? Is that only for other Haste libraries? Most haskell cabal dependencies end up needing a native library (eg: compiled c files) somewhere in their transitive dependencies (this is very unfortunate, btw).

Integrates with Cabal might mean that Haste can be installed with Cabal, but I'm not sure (ghcjs for example cannot).

How does this deal with calling arbitrary JS code from Haskell? For example, how would I use jQuery from Haste? Looks like a cool project, but that's the first thing I want to know for X to JS compilers.

You just make an FFI declaration in Haskell:

    foreign import ccall square :: Int -> Int

And use --with-js to link against a JS file:

    // square.js

    function square(x) {
        return x * x;
    }

Using jQuery would be an interesting challenge. I suppose you could just get the jQuery object and go nuts on it unsafely, or write typesafe(ish) wrapper functions to export. The “ccall” convention is also a bit disingenuous.

Source: https://github.com/valderman/haste-compiler/blob/master/doc/...

jQuery seems to be particularly dynamic even as far as Javascript libraries go, but here's how Typescript handles it: https://typescript.codeplex.com/SourceControl/latest#typings...

Since jQuery is a monad i expect a Haskell wrapper to be written very soon.

You had better be joking.

Reply on news.ycombinator.com