Making the OCaml compiler more friendly to Js_of_ocaml

[vouillon]

I have recently proposed to change the definition of Pervasives.min/max_int so that Js_of_ocaml does not have to patch the bytecode (ocaml/ocaml#19). I'm wondering what other changes we could propose that would be useful to Js_of_ocaml.

• Pervasives.min/max_int
• caml_alloc_dummy_closure
• Sys.int_size
• Sys.max_array_length
• String.concat recognize String concat #977 Compiler: recognize String.concat #1585
• map OCaml values to JavaScript objects, MAKEBLOCK is used for allocating both arrays and blocks
• caml_alloc_dummy_infix could receive arity Fix compilation of some mutually recursive functions #1393 (comment)

[hhugo]

One more PR that might break js_of_ocaml. see comment ocaml/ocaml#14 (comment)

[hhugo]

What about more debug (event) information ?

[vouillon]

What do you mean?

[hhugo]

could we improve sourcemap generation with more debug information ?

[vouillon]

Do you have anything specific in mind? I would say we already have all the needed information: for code with debugg information, we should be able to associate to any bytecode instruction a corresponding location in the source code.

[vouillon]

Code like let rec f x y = 1 and z = Some (f, h) is compiled using primitive caml_alloc_dummy to allocate a block (for all values but floats, including closures), then caml_update_dummy to fill the block with its actual contents. So we have a hack in Js_of_ocaml to be able to use a block (a JavaScript array), as if it was a function.

It would be better if a specific primitive caml_alloc_dummy_closure was used to allocate dummy closures. Even better, this primitive could be given the arity of the closure. Then, we could compile
a primitive call caml_alloc_dummy_function(2) into a function function f(x,y) {return f.fun(x,y); } which does not need any specific runtime support.

[vouillon]

I'm wondering whether we could do something for recursive modules as well. At the moment, we have a hack that replaces the bytecode implementation of CamlinternalMod by a JavaScript implementation.

[hhugo]

caml_alloc_dummy_closure => https://github.com/hhugo/ocaml/compare/jsoo_friendly

[hhugo]

limits due to runtime representation should/could be set from the runtime.

• Sys.max_array_length
• Sys.int_size (new)

[hhugo]

ocaml/ocaml#37

[hhugo]

ocaml/ocaml#36

[vouillon]

If String.copy and (^) were implemented as primitive, we could more easily generate efficient code for them.

[vouillon]

OCaml is switching to immutable strings. However, as they are implemented imperatively, based on byte sequence operations, there does not seem to be any easy way to take advantage of this.