Wasm_of_OCaml | Hacker News Reader

Wasm_of_OCaml

github.com

118 pointseriangazag52 comments

Wasm_of_ocaml is a fork of Js_of_ocaml which compiles OCaml bytecode to WebAssembly. The generated code works with Chrome beta and node V8 canary.

Sorry in advance for bikeshedding. This is a cool project and the name is clearly derived from js_of_ocaml, but does anyone know why js_of_ocaml ended up with such an awkward name in the first place? I am vaguely familiar with the "x_of_y" naming scheme in OCaml (which I also find awkward, but perhaps it sounds better in French) - is that the only reason? I can't find any discussion online, so maybe I'm really the only one who finds the name awkward.

It's just a dodgy French to English translation which then became a convention. Instead of e.g. to_string's buddy being called from_string, it was called of_string.

Here's a thread of reddit about it: https://www.reddit.com/r/ocaml/comments/6es88t/what_does_the...

I assume it also has a connection to how algebraic data types are written in OCaml. For example, the equivalent of Haskell's `Maybe` and Rust's `Option` is

  type 'a option = None | Some of 'a

So calling this project "WASM of OCaml" is one way of saying that it "wraps" OCaml code in WASM.

Right but why do they use "of" in that way for type declarations? Ends up being the same answer: it's a reasonable translation from french for a non-native english speaker.

...except that the original ML uses the same syntax, and it's Scottish.

Oh interesting, nevermind then. This makes me question the french explanation for the other thing too.

It's fairly colloquial english to say you have "some of something", I think this matches the ocaml language convention pretty nicely

It’s somewhat hard for me to decide how unnatural a translation this is as I’m used to seeing it in ocaml. My concise dictionary doesn’t have a definition that fits this use well. My non-concise dictionary describes the history of the senses of the word as “exceedingly complex”.

It has been used as a translation of the French de since the 11th century and I think it gets some senses (eg derivation) from that. With a verb meaning create, this ocaml construction is fine in modern English (eg ‘make a string of an int’) and dates back a long way (OED offers a source from 893; this is sense I. [VII.] 20. a. in the second edition). So I think partly the question is whether omitting make in make_string_of_int (or String.make_of_int) is an acceptable abbreviation in programming.

It doesn't sound better in french. Any reasonable french version should be translated as "from".

String: ficelle

Rope (advanced string): corde

Thread: fil

So string from object would like ficelle d'objet which is yeah, string from object. But the "of" thing in Ocaml is well documented. I vaguely remember them when I had an Ocaml project in my coursework.

No, “de” in French has the same meaning as “of” and sounds exactly as weird here. That’s clearly not where this comes from. Also the translation of string with this meaning is “chaîne de caractères”.

Is «chaîne de caractères» what French programmers call strings? (That would surprise me much as English-speaking programmers calling them ‘strings of characters’ would)

Yeah it's the French word. You can always say just "chaîne" when it's unambiguous. Or you can just use the English word

I think it's a great convention. It means you write

    i = int_of_string s

where the "i" is next to the "int" and the "s" is next to the "string".

    i = string_to_int s

just looks backwards to me.

The topic here isn't so much the order but whether "of" in int_of_string matches a common/typical usage of the word.

From the other comments sounds like its local style for OCaml maybe because of some French lineage, but that "int_of_string" is a function that converts a string into an int was definitely not something that I would have assumed (as opposed to 'int_from_string' or something).

It doesn't sound especially weird to me and I'm not French.

It's just "[create an] int [out] of [a] string"

"from" would have made more sense.

The words in brackets are doing all of the heavy lifting in your example though: "Of" without "out of" means "constituted by". If in isolation I saw "array_of_string" I'd definitely parse that as somehow being about str[], not "f(str) -> char[]"

Well, if the word order is the most important aspect (as it is to me) then you have to think of another word you can use instead of "of". I know that in my early Haskell programming I was writing `intOfString` where other Haskellers wrote `stringToInt`. I'm a native English speaker so it certainly had nothing to do with French! "Of" just seemed to fit naturally there. Do you think "From" or some other English word would be more natural?

The Haskell culture clearly dictates "i = fromString s".

And as a consequence, Rust has it standardized as "i = from s".

What do you do if you want to disambiguate the return type? I suppose `intFromString` works. I'm not sure what I chose `intOfString`. It's not because I'm French!

You would declare the type of the returning value:

(i :: Int) = fromString s

Although once in a while it's useful to make a short synonym for disambiguating the type, x_of_y is certainly not a short synonym, so it's not commonly used.

Better yet, compare

    f = glork_to_floob (crumb_to_glork c)

versus

    f = floob_of_glork (glork_of_crumb c)

and picture the first style inside a more complex function with more constructors/conversions.

Yes, even better example, thanks! In Haskell you get

    f = floob_of_glork . glork_of_crumb . crumb_of_zing

which is much better than

    f = glork_to_floob . crumb_to_glork . zing_to_crumb

Interesting. The pipe operator is more idiomatic in OCaml where this would be

  crumb_of_zing x |> glork_of_crumb |> floob_of_glork

versus

  zing_to_crumb x |> crumb_to_glork |> glork_to_floob

Yeah, fair. Forth especially really commits to that left-to-right order in its general style -- I like it when a language and its culture are conscious about readability in this way.

It is interesting that the "of" style is common in Ocaml where the left-to-right style is common. They seem to clash!

I would like to know what it's like to work in a fully left-to-right language, for example, to define `my_floob`:

      let my_crumb |> zing_to_crumb |> crumb_to_glork |> glork_to_floob = my_floob

In addition to Forth, R can do this too:

  x |> zing_to_crumb() |> crumb_to_glork() |> glork_to_floob() -> my_floob

But it is not idiomatic.

I assumed it was meant to evoke William of Occam.

I am French, but I feel this matches definitions 2a and 3 on https://www.merriam-webster.com/dictionary/of :

* "used as a function word to indicate origin or derivation, eg. a man of noble birth" (js code comes from ocaml code)

* "used as a function word to indicate the component material, parts, or elements or the contents, eg. throne of gold / cup of water" (js application made of ocaml code)

"Cup of water" isn't a great example because it would imply then cup was made from water. This makes more sense when you realize "cup of water" is lazy speech for "cup full of water".

"of" usually implies a state of being while "from" implies a transformation.

"JS of Ocaml" implies that the JS is Ocaml, but that's not true as it is transformed. "JS from Ocaml" would be more accurate.

The of in Cup of water act as a normal genitive. It communicates that the cup relates to water and the only reasonable relation between a cup and an edible liquid is that the cup contains the liquid

I always assumed this convention was just using "of" in the same sense as function composition. From wikipedia:

> The notation g ∘ f is read as "g of f "...

Considering how math heavy is OCaml and how formal is/were French mathematics, especially post high school, this is most likely the reason.

I believe this is because in French you tend to say "x of y".

It is named like the <x>_of_<y> functions, yes. "Of" and "from" are both "de" in French. A native English speaker would use "from" there, but whoever named those functions used "of."

Yeah most likely just french translation. A more accurate translation would have been "from" in this context.

`js_from_ocaml`, `string_from_int`, etc would have been clearer in english.

If i didn't speak Spanish it would bother me a lot more.

Even the standard library isn't consistent on that. There are plenty of "Something.to_string"

But "standard library" never was a strong point of OCaml anyway so I guess meh shrugs

On this subject, a question. Has anybody done this with F#? To have F# compile to WASM instead of .NET. Thus have a F# program able to execute on WASM without needing .NET.

Isn't Blazor supposed to do that?

That's right, and there's Bolero too. From my understanding, Blazor is by Microsoft and aimed at C# primarily while Bolero is from the wider community and aimed at F#. https://fsbolero.io/

Thank You. I had not heard of Bolero.

Bolero is built on top of Blazor.[0]

https://fsbolero.io/docs/

I’m not sure on the level of F# support, but Blazor supports full ahead-of-time compilation of .NET code to WASM:

“Blazor WebAssembly supports ahead-of-time (AOT) compilation, where you can compile your .NET code directly into WebAssembly. AOT compilation results in runtime performance improvements at the expense of a larger app size.

Without enabling AOT compilation, Blazor WebAssembly apps run on the browser using a .NET Intermediate Language (IL) interpreter implemented in WebAssembly”

https://learn.microsoft.com/en-us/aspnet/core/blazor/host-an...

If something works based on .NET IL, then it works equally well for F# as C#. Both are first class languages in .NET. Anything written in one can be used from the other (though it is often very un-idiomatic without a wrapper). Both compilers generate the same IL.

Not really, as there are restrictions, and for example .NET Native didn't handle some of the IL pattern required by F#. This was never fixed, even though there are some kind of workarounds.

F# also has some issues with some IL constructs generated by C#, with features not exposed in F#, like protected, which can be consumed, but not authored.

I wasn't aware of the issues with .NET Native.

Your second point is exactly what I said, though. F# can consume things written in C#. Whether the F# language team wants to include some specific feature is a different question. C# libraries that use the protected attribute can be used transparently in F#.

They are different languages with a shared runtime. You can't write a computation expression in C#, but an F# library function that is implemented with CEs can still be called from C#.

> C# libraries that use the protected attribute can be used transparently in F#.

Only if you don't need to write data types that need to be consumed by said libraries, as to express those types you need C# features.

Another two key examples are the recent trends from .NET team to depend on Roslyn and code generators, both not supported by F#, so the language can't be fully used in such workloads without a little bit of C# glue.

Really, F# might be from Microsoft, but the .NET team handles it as if it was a 3rd party guest language.

Yes. Think this is the frustrating part. MS kind of broadcast like it is equal, full language. But .NET doesn't support everything.

I think this is why .NET core doesn't have typeproviders?

We've explored this. Not everyone will have this problem, but with Blazor, you have to export almost everything about F#/.NET to WASM.

The Fable compiler team seems to have made steady progress towards a Rust compilation target which would solve this, but I'm not clear on where that works or how.

Yes. Darklang was originally in OCaml using js_of_ocaml, and we ported it to F# using Blazor (https://github.com/darklang/dark/tree/main/backend/src/Wasm). It works.

We found that in dotnet 6, the code was much slower, with long startup times and a much bigger download, than in js_of_ocaml. It also had a lot of issues in running in a Webworker, which wasn't the case for js_of_ocaml.

In dotnet 7, the webworker issues are better and AOT is easier, so startup is faster. Download sizes are still bad, and it's still slower than js_of_ocaml.

However, dotnet allows almost any code to run in WASM, which js_of_ocaml had large limitations. This meant a decent chunk of functionality had to be worked around to make separate js vs native targets, which also was a massive pain and took a long time. Dune's virtual targets wasn't ready at the time - I think we were one of the test cases for it.

Grain?

Reply on news.ycombinator.com