Hacker News new | past | comments | ask | show | jobs | submit login
SMLtoJs – A Standard ML to JavaScript Compiler (2008) (smlserver.org)
42 points by networked on July 26, 2015 | hide | past | favorite | 10 comments



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/

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


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

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

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


A similar, more mature & full-featured, approach. Has the power of the Ocaml community going for it. Quite the head start. :)


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.


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.


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.


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


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.


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.


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.




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: