
SMLtoJs – A Standard ML to JavaScript Compiler (2008) - networked
http://www.smlserver.org/smltojs/
======
seliopou
There is also a compiler for OCaml bytecode to JavaScript, called
js_of_ocaml[0]. It's been around for a while, but I've only recently started
using it. It's got a pretty good FFI, and makes futures-based programming via
lwt[1] very convenient.

[0]: [http://ocsigen.org/js_of_ocaml/](http://ocsigen.org/js_of_ocaml/)

[1]: [http://ocsigen.org/lwt/](http://ocsigen.org/lwt/)

~~~
birdsbolt
There's also a compiler for Haskell to JavaScript called GHCJS[0]. Many of
Haskell libraries can be compiled easily. I think someone compiled Pandoc
directly to JS and made a web interface and bundled the app[2].

One interesting things besides web that people have been doing with it is
writing Atom editor plugins[1].

[0]: [https://github.com/ghcjs/ghcjs](https://github.com/ghcjs/ghcjs)

[1]: [http://edsko.net/2015/02/14/atom-
haskell/](http://edsko.net/2015/02/14/atom-haskell/)

[2]: [http://markup.rocks/](http://markup.rocks/)

------
nickpsecurity
This will help in the battle to verify correctness or security of client-side
code. Pre-existing tools and code supporting that for ML can be applied
immediately. Covert channels & information flow are getting more mainstream
attention in recent years. Might work those issues out with Flow Caml, recode
equivalent in this, and compile to JS. Would need an analysis on the JS code &
runtime itself, though.

I mainly see it useful for what ML is always good at: developer tools. ML has
been used to write many robust tools offline. There are also many tools hosted
online or in a browser. Might be a step toward (a) moving existing tools
online for easy experimentation and (b) deploying new ones.

~~~
CHY872
In what situation might you use this instead of ocaml? There are a lot of
drawbacks of using Standard ML in general, so I'd be interested in seeing if
there are any advantages at all.

~~~
nickpsecurity
A lot of academic tools in verification and one in covert channel analysis are
specific to SML. Such things might make me use this instead of Ocaml if SML's
libraries improved to a similar level. For right now, I'd stick with Ocaml.

~~~
CHY872
Thanks - that makes sense. My understanding is that SML's libraries will never
improve to a similar level, sadly.

~~~
nickpsecurity
Between INRIA and Jane St, it probably won't. There's just so much work going
on in Ocaml community. The thing I like most about INRIA and Ocaml academics
is they often build things that are useful. Much SML projects are toys.

~~~
CHY872
Add OCaml Labs (at Cambridge) to that list; their work is helping to remove
some of the big gripes with OCaml whilst Mirage is genuinely interesting new
(I think) work.

~~~
nickpsecurity
Oh yeah: they rock! Especially Mirage. That project combines a number of
lessons learned from robust systems in the past while adding Ocaml to the mix.
Add a robust middleware, a separation kernel, and certifying compiler with the
right security checks/defaults to make MirageOS a bad-to-the-bone hosting
solution.

