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.
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.
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.
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).
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?
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.
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[]"
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.
* "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
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."
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)
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”
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.
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.
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.
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/
