Wasm_of_OCaml(github.com) |
Wasm_of_OCaml(github.com) |
Here's a thread of reddit about it: https://www.reddit.com/r/ocaml/comments/6es88t/what_does_the...
type 'a option = None | Some of 'a
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.
`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 = int_of_string s
i = string_to_int s
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).
f = glork_to_floob (crumb_to_glork c)
f = floob_of_glork (glork_of_crumb c)
> The notation g ∘ f is read as "g of f "...
* "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)
"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.
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.
But "standard library" never was a strong point of OCaml anyway so I guess meh shrugs
“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...
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.
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.
f = floob_of_glork . glork_of_crumb . crumb_of_zing
f = glork_to_floob . crumb_to_glork . zing_to_crumb crumb_of_zing x |> glork_of_crumb |> floob_of_glork
zing_to_crumb x |> crumb_to_glork |> glork_to_floobF# 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#.
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.
And as a consequence, Rust has it standardized as "i = from s".
It's just "[create an] int [out] of [a] string"
"from" would have made more sense.
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 x |> zing_to_crumb() |> crumb_to_glork() |> glork_to_floob() -> my_floob
(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 think this is why .NET core doesn't have typeproviders?