[hongboz]

Hi, thanks for your interest in it.

This project has been released to exchange some ideas and collect feedback from the OCaml and JavaScript communities. It is still in an very early stage and more like research projects though we already had some good results.

Note that ocamlscript is inspired from typescript and js_of_ocaml, we like the readability of typescript generated js code, while don't want to loose the expressivity of a powerful langauge, ocaml, here in particular.

The main difference from js_of_ocaml is that js_of_ocaml maps the whole bytecode program into a js file while ocamlscript maps an ocaml module to es6 module.

Indeed, there is some difference in the runtime representation between js_of_ocaml and ocaml, for example, ocamlscript uses js string and array for ocaml string and arrray(we do this since we want an optimal js output at the price of a bit runtime incompability), this may make interaction between js_of_ocaml and ocaml a bit harder, but that's exactly why we made an early release to hear what other people may think. js_of_ocaml is an excellent project and we learned a lot from it and will seek some collaborations to share some workload.

[jordwalke]

Question for hongboz and Drup about F-lambda:

OCamlScript does some cross-module optimization it seems. That's really cool, and js_of_ocaml does several optimizations as well, but for both approaches, it seems we'll not be able to take advantage of all really great f-lambda optimizations to come because they happen at a compiler stage after OCamlScript and js_of_ocaml have already intercepted their intermediate representations. Do you (or Drup) have thoughts on that?

[jordwalke]

It would be great to see a list of known/anticipated compatibility issues. For example, I notice that when compiling `String.set` with OCamlScript, the generated JS ends up trying to set/mutate a character in the JS string, which has no effect because JS strings are immutable. (I'll file a github issue). I imagine there will be several small issues like this and it would be good to get a sense for how much work it would be to solve that long tail of compatibility work. In the process, I think the community can help determine if this approach could ever practically match the near-perfect level of compatibility that js_of_ocaml has achieved via byte code compilation - and whether or not it matters. To me, compatibility is very important, but so is debugability. It might be clear that it's okay to compromise the readability of OcamlScript in order to achieve more compatibility without compromising debugability (for example, using a `new MLString("xyz")` wrapper that uses a JS `String` by default for performance, but then swaps it out upon any mutation. (Or perhaps you can limit it to programs that have disabled string mutations in later versions of OCaml).

The good news is that if you can achieve perfect compatibility with this approach, then I believe that runtime performance becomes less of a concern and OCamlScript's job gets a lot easier. This is because, if you've achieved perfect compatibility, you can easily compile your project with another toolchain such as js_of_ocaml, that has equal compatibility, but (in this hypothetical scenario) had chosen to focus more on performance instead of debugability - without changing anything in your program.

This would free you up to not have to worry about applying any optimizations in this readable/debuggable mode - you get to focus entirely on whatever makes the development flow faster/easier. (You'd probably still want tail call optimization because order of memory usage could be considered a key part of compatibility).

Similarly, I wonder if the existence of a fully compatible, (hypothetically) slow runtime performance, but perfectly debugable compiler backend, would then free up js_of_ocaml from some of the constraints/work that is required to make their code output reasonably simple/debuggable. Does the existence of a fully compatible OCamlScript mean that js_of_ocaml's job gets easier?

I'm excited to discuss how the two projects could potentially become an asset to each other.

edit: I started a discussion on Github here: https://github.com/bloomberg/ocamlscript/issues/12