Haste – A Haskell to JS Compiler

http://hackage.haskell.org/package/haste-compiler

by freqheist • 13 years ago

64 23 13 years ago

hackage.haskell.org

tieTYT2• 13 years ago

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

ocharles• 13 years ago

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

egonschiele• 13 years ago

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.

evincarofautumn2• 13 years ago

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/...

marshray3• 13 years ago

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

fosap2• 13 years ago

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

Zariel• 13 years ago

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

miga• 13 years ago

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.

cantankerous2• 13 years ago

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

marshray3• 13 years ago

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'

cantankerous2• 13 years 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• 13 years 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.

fosap2• 13 years ago

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

spion• 13 years 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/source...

tieTYT2• 13 years 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 :)

munificent• 13 years 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?

marshray3• 13 years 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• 13 years ago

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

aroberge• 13 years ago

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.

cies• 13 years ago

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

Haste – A Haskell to JS Compiler

Related Stories