3 ms·

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 integrati

by 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. :)

jordwalke 11y ago
Drup, By the way, I really have appreciated the absolute simplicity of js_of_ocaml - it's pretty great how you can just take any byte code file and run it in any JS engine with great performance - it's amazing really. I really love how js_of_ocaml does dead code elimination, and inlining among other features. It seems like the primary difference is that the goals of js_of_ocaml gravitate more towards taking an app/library that had already been fully tested/debugged in OCaml and then running that thing in the browser with some nice debugging facilities that let you see the source code and kind of step through in the more rare event that something goes wrong. I can't speak for this new approach here, but it seems to be more focused on using the JS target as the core development workflow for rapid iteration. I can see why that's appealing. Everyone knows how to use the browser debugger, and JS is one of most ubiquitous byte code formats ever. Running your OCaml app in the browser also gives you all kinds of really great timing and memory profiling tools that help you detect leaks (that even tells you something about the nature of your program when compiling OCaml to machine code). Obviously, I wish there was a single toolchain that could actually do both though - a toolchain that you could use to get very JS-friendly code generation so the debugging/value printing/console inspection works just like it does in JS, but then would also let you do a js_of_ocaml style compilation based purely on an OCaml byte code object file (edit: or some kind of representation of the whole program) which would be free to remove and obscure record field names if it so chose. (BTW: The difference in object representation (record field names are not obscured) seems to be the very thing that makes the values inspectable in the browser. Maybe there are some of OCamlScript's compiler patches that could be accepted in upstream ocaml so that the same can be achieved with js_of_ocaml?).
jordwalke 11y ago
Drup: Also, if it wasn't abundantly clear (to you or others) - I believe js_of_ocaml to be perhaps the best systems language compile-to-js toolchain that I've ever discovered (and I've looked extensively for others) - so I hope you can fully appreciate just how valuable it continues to be, to me personally and many others. I have a question about your comment: "It's probably pretty easy to improve js_of_ocaml on that though, given the current state." Would this also require patching the compiler to preserve record field names and avoid name mangling in general? And I have a question about your comment on reddit which implies that maintaining a backend would be difficult to sustain: Do you believe that a seamlessly debuggable JavaScript backend, could generate the necessary amount of attention required to sustain such a backend, given how much more widely accessible end-end OCaml development would become as a result of its existence?

by Drup 11y ago

jordwalke 11y ago

Drup, By the way, I really have appreciated the absolute simplicity of js_of_ocaml - it's pretty great how you can just take any byte code file and run it in any JS engine with great performance - it's amazing really. I really love how js_of_ocaml does dead code elimination, and inlining among other features. It seems like the primary difference is that the goals of js_of_ocaml gravitate more towards taking an app/library that had already been fully tested/debugged in OCaml and then running that thing in the browser with some nice debugging facilities that let you see the source code and kind of step through in the more rare event that something goes wrong. I can't speak for this new approach here, but it seems to be more focused on using the JS target as the core development workflow for rapid iteration. I can see why that's appealing. Everyone knows how to use the browser debugger, and JS is one of most ubiquitous byte code formats ever. Running your OCaml app in the browser also gives you all kinds of really great timing and memory profiling tools that help you detect leaks (that even tells you something about the nature of your program when compiling OCaml to machine code). Obviously, I wish there was a single toolchain that could actually do both though - a toolchain that you could use to get very JS-friendly code generation so the debugging/value printing/console inspection works just like it does in JS, but then would also let you do a js_of_ocaml style compilation based purely on an OCaml byte code object file (edit: or some kind of representation of the whole program) which would be free to remove and obscure record field names if it so chose. (BTW: The difference in object representation (record field names are not obscured) seems to be the very thing that makes the values inspectable in the browser. Maybe there are some of OCamlScript's compiler patches that could be accepted in upstream ocaml so that the same can be achieved with js_of_ocaml?).

jordwalke 11y ago

Drup: Also, if it wasn't abundantly clear (to you or others) - I believe js_of_ocaml to be perhaps the best systems language compile-to-js toolchain that I've ever discovered (and I've looked extensively for others) - so I hope you can fully appreciate just how valuable it continues to be, to me personally and many others. I have a question about your comment: "It's probably pretty easy to improve js_of_ocaml on that though, given the current state." Would this also require patching the compiler to preserve record field names and avoid name mangling in general? And I have a question about your comment on reddit which implies that maintaining a backend would be difficult to sustain: Do you believe that a seamlessly debuggable JavaScript backend, could generate the necessary amount of attention required to sustain such a backend, given how much more widely accessible end-end OCaml development would become as a result of its existence?