> The first question I usually get ... is “Why not Haskell?”.
> The answer is JavaScript.
My current favorite language for this is Elm[1]. It compiles to JS, is based on Haskell, and has a few simple differences between either[2].
Elm doesn't let you use the tons of available Haskell libraries, and makes it slightly painful to integrate with JS. But it's the coolest thing for the web so far. And here's why:
It uses a completely declarative state machine to model a fully interactive and complete GUI! This is the dream React.js and Om didn't even know they were heading towards! And yes, it is as good as it sounds.
3. a technique for modeling a GUI as a declarative state machine
PureScript only competes with #1 and #2 here. Where Elm really shines is #3, which #2 helps with a lot.
Technically #3 could be done in any language. But it really helps to model it in such an expressive language with immutable data and no side-effects (except via Signals).
I won't argue that Elm does anything other than an exemplary job at #3, but it is worth noting that there are some interesting efforts to build similar functionality in PureScript libraries:
To me, this is the benefit of PureScript - yes, you have to do a little more work, because you don't get these things for free from the compiler and tools, but you gain complete control over your application structure. You're not forced to work in some ambient Signal category.
You can probably implement Elm in PureScript pretty trivially, AFAICT. AFAIK Elm doesn't have any static guarantees about lack-of-space leaks or lack-of-time leaks. Or, maybe it just lacks higher-order-signals? (Which would mostly prevent those sorts of things happening). I found Neel Krishnaswami's papers on a static way to decide/prevent these things statically very interesting. I haven't found any implementation of his ideas, but they seem pretty solid: http://www.cs.bham.ac.uk/~krishnan/
Could anyone summarize how well PureScript and Elm treat sourcemaps/debugging in the browser? For a while I thought that js_of_ocaml didn't support sourcemaps, but it turns out, one of my dependencies wasn't compiled with debug flag (-g) and I was able to get a pretty good sourcemaps/debugging experience in Chrome dev tools once I fixed that issue. Is there something js_of_ocaml can learn from PureScript/Elm's JS compilation toolchain? Or should we look to CLJS (which I'm also really excited about) as the best example?
I can't really comment on source maps in Elm, but the approach in PureScript has been to generate clean, readable JS which is debuggable directly. Source maps are on the roadmap, but not really a priority right now. I haven't heard any complaints about the ability to debug compiled PureScript yet.
That's a nice approach for debugging! If the mapping is close enough, I don't mind reading the JS output. I'm curious about the general approach to compilation, though. It seems like a statically typed language could take advantage of the knowledge of types to generate an even more efficient version of the program that uses typed arrays and views (though, yes, it would require implementing a garbage collector unless relying on some kind of WeakMap in the JS engine).
I've heard of garbage collected languages compiling to LLVM which would allow Emscripten to assist you, but I've also heard that LLVM has a really hard time with GC languages.
Right now, the translation is very direct. My basic rule of thumb is - only perform those optimizations which the user opts into. Some things are standard though, like a few inlining rules and tail call elimination, but the plan is to provide a rewrite rules engine so that the developer can be as fine-grained as they like when it comes to optimizations.
As far as I can tell Elm is more of a GUI focused language, when I was evaluating AltJS languages I was looking for something a bit more low level. The JS and DOM bindings of js_of_ocaml were what really sold me although I didn't mention this in the post.
hey didyoucheckthe I'm working on a new programming language that I think you may be interested if you like Elm. Couldn't find your email in your profile, but mine is cammarata.nick@gmail.com. I'd love to show you
> The answer is JavaScript.
My current favorite language for this is Elm[1]. It compiles to JS, is based on Haskell, and has a few simple differences between either[2].
Elm doesn't let you use the tons of available Haskell libraries, and makes it slightly painful to integrate with JS. But it's the coolest thing for the web so far. And here's why:
It uses a completely declarative state machine to model a fully interactive and complete GUI! This is the dream React.js and Om didn't even know they were heading towards! And yes, it is as good as it sounds.
[1]: http://elm-lang.org/
[2]: http://elm-lang.org/learn/FAQ.elm
EDIT:
Also, Elm fixed Haskell's awful syntax record name collision problem, and awesomely too!