I’m looking for information about using Js_of_ocaml with Google’s Closure compiler and tools. I tried using the latter to compile some of the test code from Jsoo but it throws tons of “could not determine type of this expression” errors. I understand there are some restrictions on the code the Closure compiler can handle. Is it feasible with Jsoo?
Thanks,
gregg
I read rapidly through Understanding the Restrictions Imposed by the Closure Compiler | Google Developers and couldn’t find things that look problematic to me, but you shouldn’t take my word for it as I’m quite new to the kind of code that js_of_ocaml can output. Maybe @hhugo will know better.
Have you taken care to give Closure a standalone JS file (i.e. not the result of a partial compilation by js_of_ocaml)?
Nope. I’m pretty much flying blind. I know Clojurescript uses the Closure compiler to good effect; it evidently does some superbad optimizations so I thought I’d give it a try with jsoo. I’m the OBazl author; I’ve got jsoo building under bazel, and I can feed the output to the js_binary rule of the rules_js ruleset, which automatically handles the node toolchain, so it can be run under Bazel (e.g. bazel run compiler/tests-ocaml/lib-bigarray:bigarrays.exe.js). Thought I might see if I can get it working with rules_closure.
I’m have no experience at all with OBazl; I guess it would be needed to inspect the code at the locations of the errors to know more.
In order to use Closure’s advanced optimizations, it does require input sources that are effectively a peculiar subset of Javascript. In my experience, compilers that emit JS sources (like jsoo) need to be written specifically with Closure in mind in order to ensure that they don’t fall outside of the subset it can accept safely. I strongly doubt that that is the case for jsoo.
(Cite: I was an early contributor to the Clojurescript compiler, and had my hands in a lot of the code that emitted JS sources that had to conform to Closure’s constraints.)
That said, I reckon that Closure probably isn’t the best route for optimizing jsoo output. Closure is well-suited for optimizing hand-written Javascript, and as effectively the target for compile-to-js compilers for languages that don’t have optimizing compilers available. That’s not the case for OCaml though; and while e.g. flambda obviously isn’t relevant given jsoo’s approach, all of the optimizations that Closure provides could be implemented upstream of the bytecode that jsoo operates over. Obviously nontrivial work, and it doesn’t help users of jsoo today, but it wouldn’t require anything novel (compared to a language like Clojurescript that really does need Closure, as building an optimizing compiler for Clojure would likely involve multiple career-defining dissertations and research breakthroughs).