5 ms·

I'm still wondering why js_of_ocaml couldn't be improved. You yourself did some work towards that, mostly out of the compiler itself. We have multiple standard

by Drup 11y ago

I'm still wondering why js_of_ocaml couldn't be improved. You yourself did some work towards that, mostly out of the compiler itself. We have multiple standard libraries, two concurrency library. It has damaged and divided the community significantly. And now two compilers to js ? :/

hongboz 11y ago
Author here, just created a new account : ). I think ocamlscript is complementary to js_of_ocaml, actually it is inspired from js_of_ocaml. For those who like to write ocaml only application, js_of_ocaml is perfect, ocamlscript is designed to help easier integration with existing javascript system. Design goals here: http://bloomberg.github.io/ocamlscript/ http://bloomberg.github.io/ocamlscript/
- Drup 11y ago
  That is how you justify the project, and it makes sense, when you look at it with a microscope. But my remark still stand: we now have two compilers to js, their API/FFI is not the same, so you can't factorize work, and the integration work could be made on js_of_ocaml too (see alain frisch's project).
  - jordwalke 11y ago
    Hi Drup, I'd be curious to hear about the work that Alain is doing. Do you have a link?
    - Drup 11y ago
      There you go : https://github.com/LexiFi/gen_js_api https://github.com/LexiFi/gen_js_api
      - hongboz 11y ago
        actually we have great relationship with Lexifi, and we did exchange some ideas about ocamlscript before, I think mostly we are on the same page, there is enough room for two compilers :-)
- truncate 11y ago
  Its good to see ocaml->js back to life. Have you considered supporting TCO or arbitrarily deep stack? I'm just curious how often could we reuse ocaml libraries with just tail call to loop conversion.
  - hongboz 11y ago
    self tail call is supported. mutual recursive tailcall can be done partially, but there is not a strong guarantee
- cannam 11y ago
  In the (nice) immutable map example on that page, a reference cell is used & updated each time something is added to the map. How would the JS output differ if you built the map using a fold or similar, without any refs?
  - jordwalke 11y ago
    Before that, I'd ask if the implementation of OCaml's map is at all similar to the implementation of Immutable.js's Map. Different internal data structures/algorithms are probably the most likely explanation for any difference. Still, it's nice to see a benchmark that shows how OCaml compiled to JS is competitive in performance, even when compared to a very popular library that is known for performing well.
    - cannam 11y ago
      Also a fair point, and I take your implication that the effect of a change to the outer loop syntax would probably be lost in the noise. It just struck me that using ref cells and loops feels like a concession to writing Javascript-style code in the first place (I grant in this particular case it makes the code more obvious) and I wondered how much difference it actually makes. Is the compiler able to flatten a fold into a similar loop? Or do you get a readable fold call in the JS code and, if so, is it much slower? Or neither?
  - hongboz 11y ago
    List.fold_left is compiled into a while loop in ocamlscript. The main reason that I used for loop is that the generated code is the same as hand written js, so the comparison is more reasonable Edit: I am a practical programmer, I am in favor of both for loop and recursion as long as it is readable
jordwalke 11y ago
Small correction: I did not improve js_of_ocaml besides giving feedback (which included feedback about the need to not mangle names). Before Babel for JS came out, there were tons of different solutions to compiling ES6 features into ES5, and the decision about which toolchain to use would fatigue newcomers to the community. But it was the fact that the community was relatively accepting of new spinoffs that Babel was able to gain momentum, and increase its quality to the point where it is the de factor tool that everyone uses - and it's really good. As a consumer of the compiler, I don't necessarily consider multiple options a bad thing as long as something of really high quality emerges. (Although I can see how for something like an Async library (that introduces incompatibilities between dependencies) that would be particularly frustrating to have too many options) It looks like OCamlScript used some good ideas from js_of_ocaml. Maybe js_of_ocaml can end up sharing some of the good ideas from OCamlScript so that it can also have very readable/debugable code and ecosystem integration?
- Drup 11y ago
  I was actually talking about your work for CommonML[1], which I count as improvements to the "js_of_ocaml ecosystem". ;) My issue here is that both are strictly incompatible and that you can't write FFI to a library for both. [1]: https://github.com/jordwalke/CommonML https://github.com/jordwalke/CommonML
- jordwalke 11y ago
  Drup, Ah, yes - CommonML does indeed have built in support for js_of_ocaml. And I think you have valid points. I'm curious though, since both js_of_ocaml have seamless interop with JS (seamless in terms of memory model), couldn't the two have seamless interop between each other by going through JS bindings? I'm curious, do you think it's possible or practical to create an OCaml to JS compiler that has the strengths of both approaches?
  - Drup 11y ago
    It doesn't seem that ocamlscript and js_of_ocaml are using the same memory representation for OCaml values, so that's a first issue. At least for the integration between the js world and the ocaml world, I do believe it is possible. yes. For readability of the js produced, I really can't tell. It's probably pretty easy to improve js_of_ocaml on that though, given the current state. :)
vitriol83 11y ago
I would say the main problem with the OCaml community is it's too small. More projects are welcome imo, even if it inevitably means some duplication of effort. After all js_of_ocaml is free to take some of the more desirable features.

by Drup 11y ago

hongboz 11y ago

Author here, just created a new account : ). I think ocamlscript is complementary to js_of_ocaml, actually it is inspired from js_of_ocaml. For those who like to write ocaml only application, js_of_ocaml is perfect, ocamlscript is designed to help easier integration with existing javascript system. Design goals here: http://bloomberg.github.io/ocamlscript/ http://bloomberg.github.io/ocamlscript/

Drup 11y ago
That is how you justify the project, and it makes sense, when you look at it with a microscope. But my remark still stand: we now have two compilers to js, their API/FFI is not the same, so you can't factorize work, and the integration work could be made on js_of_ocaml too (see alain frisch's project).
- jordwalke 11y ago
  Hi Drup, I'd be curious to hear about the work that Alain is doing. Do you have a link?
  - Drup 11y ago
    There you go : https://github.com/LexiFi/gen_js_api https://github.com/LexiFi/gen_js_api
    - hongboz 11y ago
      actually we have great relationship with Lexifi, and we did exchange some ideas about ocamlscript before, I think mostly we are on the same page, there is enough room for two compilers :-)
truncate 11y ago
Its good to see ocaml->js back to life. Have you considered supporting TCO or arbitrarily deep stack? I'm just curious how often could we reuse ocaml libraries with just tail call to loop conversion.
- hongboz 11y ago
  self tail call is supported. mutual recursive tailcall can be done partially, but there is not a strong guarantee
cannam 11y ago
In the (nice) immutable map example on that page, a reference cell is used & updated each time something is added to the map. How would the JS output differ if you built the map using a fold or similar, without any refs?
- jordwalke 11y ago
  Before that, I'd ask if the implementation of OCaml's map is at all similar to the implementation of Immutable.js's Map. Different internal data structures/algorithms are probably the most likely explanation for any difference. Still, it's nice to see a benchmark that shows how OCaml compiled to JS is competitive in performance, even when compared to a very popular library that is known for performing well.
  - cannam 11y ago
    Also a fair point, and I take your implication that the effect of a change to the outer loop syntax would probably be lost in the noise. It just struck me that using ref cells and loops feels like a concession to writing Javascript-style code in the first place (I grant in this particular case it makes the code more obvious) and I wondered how much difference it actually makes. Is the compiler able to flatten a fold into a similar loop? Or do you get a readable fold call in the JS code and, if so, is it much slower? Or neither?
- hongboz 11y ago
  List.fold_left is compiled into a while loop in ocamlscript. The main reason that I used for loop is that the generated code is the same as hand written js, so the comparison is more reasonable Edit: I am a practical programmer, I am in favor of both for loop and recursion as long as it is readable

jordwalke 11y ago

Small correction: I did not improve js_of_ocaml besides giving feedback (which included feedback about the need to not mangle names). Before Babel for JS came out, there were tons of different solutions to compiling ES6 features into ES5, and the decision about which toolchain to use would fatigue newcomers to the community. But it was the fact that the community was relatively accepting of new spinoffs that Babel was able to gain momentum, and increase its quality to the point where it is the de factor tool that everyone uses - and it's really good. As a consumer of the compiler, I don't necessarily consider multiple options a bad thing as long as something of really high quality emerges. (Although I can see how for something like an Async library (that introduces incompatibilities between dependencies) that would be particularly frustrating to have too many options) It looks like OCamlScript used some good ideas from js_of_ocaml. Maybe js_of_ocaml can end up sharing some of the good ideas from OCamlScript so that it can also have very readable/debugable code and ecosystem integration?

Drup 11y ago
I was actually talking about your work for CommonML[1], which I count as improvements to the "js_of_ocaml ecosystem". ;) My issue here is that both are strictly incompatible and that you can't write FFI to a library for both. [1]: https://github.com/jordwalke/CommonML https://github.com/jordwalke/CommonML
jordwalke 11y ago
Drup, Ah, yes - CommonML does indeed have built in support for js_of_ocaml. And I think you have valid points. I'm curious though, since both js_of_ocaml have seamless interop with JS (seamless in terms of memory model), couldn't the two have seamless interop between each other by going through JS bindings? I'm curious, do you think it's possible or practical to create an OCaml to JS compiler that has the strengths of both approaches?
- Drup 11y ago
  It doesn't seem that ocamlscript and js_of_ocaml are using the same memory representation for OCaml values, so that's a first issue. At least for the integration between the js world and the ocaml world, I do believe it is possible. yes. For readability of the js produced, I really can't tell. It's probably pretty easy to improve js_of_ocaml on that though, given the current state. :)

vitriol83 11y ago

I would say the main problem with the OCaml community is it's too small. More projects are welcome imo, even if it inevitably means some duplication of effort. After all js_of_ocaml is free to take some of the more desirable features.