Change the semantic of MlBytes.toString

[hhugo]

Until now, MlBytes.toString() would return a utf16 javascript string.

This is becoming problematic now that we want to change the representation of ocaml string to use JavaScript strings.
The reason is that JavaScript VMs will transparently rely on the toString method when converting a value to a primitive type. For example, the following snippet will behave differently depending on how we represent strings.

let get o (name : string) = Js.Unsafe.get o name

function get(o, name) { return o[name] }

• If implemented like ocaml bytes, a conversion from utf8 to utf16 will happen (the vm will call toString)
• If implemented like a javascript string, no conversion will happen

This PR propose to change the semantic of MlBytes.toString() to not apply the conversion to utf16 and return the raw sequence of bytes.

[TyOverby]

What is the type of this.c?

[hhugo]

See the top of that file. It describes the memory representation of mlBytes

[dbuenzli]

If I understood correctly @hhugo's explanations in the xrefs, a side effect of that PR is that caml_js_{get,set,delete} can be given for their string argument either:

• A JavaScript string
• An US-ASCII OCaml string

I had naively expected that caml_js_object and caml_js_meth_call would behave the same way. That is however not the case since they call caml_jsstring_of_string on their string arguments and thus really expect an OCaml string.

Is that expected behaviour or something that was overlooked ?

[hhugo]

Looking at the Js_of_ocaml.Js implementation:
caml_js_{set,get,delete} are polymorphic on all their arguments and results.
caml_js_object and caml_js_meth_call expect an ocaml string.

The inconsistency is unfortunate. One could imagine introducing more primitives to have versions of caml_js_object and caml_js_meth_call expecting JavaScript string