Wasm_of_OCaml(github.com)
github.com
Wasm_of_OCaml
https://github.com/ocaml-wasm/wasm_of_ocaml
52 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...
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
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 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.
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.
`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.
I think it's a great convention. It means you write
i = int_of_string s
i = string_to_int s
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).
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).
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".
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.
(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.
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.
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[]"
Better yet, compare
f = glork_to_floob (crumb_to_glork c)
f = floob_of_glork (glork_of_crumb c)
Yes, even better example, thanks! In Haskell you get
f = floob_of_glork . glork_of_crumb . crumb_of_zing
f = glork_to_floob . crumb_to_glork . zing_to_crumbInteresting. The pipe operator is more idiomatic in OCaml where this would be
crumb_of_zing x |> glork_of_crumb |> floob_of_glork
zing_to_crumb x |> crumb_to_glork |> glork_to_floobYeah, 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`:
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_floobIn addition to Forth, R can do this too:
x |> zing_to_crumb() |> crumb_to_glork() |> glork_to_floob() -> my_floob
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 "...
> 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 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)
* "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.
"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
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."
I assumed it was meant to evoke William of Occam.
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.
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
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
But "standard library" never was a strong point of OCaml anyway so I guess meh shrugs
I believe this is because in French you tend to say "x of y".
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.
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...
“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.
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#.
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.
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?
I think this is why .NET core doesn't have typeproviders?
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.
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.
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.
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.
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/
Bolero is built on top of Blazor.[0]
https://fsbolero.io/docs/
https://fsbolero.io/docs/
Thank You. I had not heard of Bolero.
Grain?