Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wasm_of_OCaml

github.com

Post reply on HN
Print view View original

41–50 of 53 posts

Re: Wasm_of_OCaml

#41

Post by dawnofdusk »

dan-robertson wrote: post #38
brmgb wrote: post #31

Earlier quoted context omitted.

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

Re: Wasm_of_OCaml

#42

Post by marcosdumay »

tome wrote: post #33
marcosdumay wrote: post #28

Earlier quoted context omitted.

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.

Re: Wasm_of_OCaml

#44

Post by pjmlp »

greggyb wrote: post #35
stetrain wrote: post #7

Earlier quoted context omitted.

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…

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.

Re: Wasm_of_OCaml

#45

Post by greggyb »

pjmlp wrote: post #44
greggyb wrote: post #35

Earlier quoted context omitted.

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#.

Re: Wasm_of_OCaml

#46

Post by pjmlp »

greggyb wrote: post #45
pjmlp wrote: post #44

Earlier quoted context omitted.

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# libr…

> 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.

Re: Wasm_of_OCaml

#47

Post by tome »

abecedarius wrote: post #40
tome wrote: post #14

Earlier quoted context omitted.

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.

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

Re: Wasm_of_OCaml

#48

Post by nequo »

tome wrote: post #47
abecedarius wrote: post #40

Earlier quoted context omitted.

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

Re: Wasm_of_OCaml

#49

Post by abecedarius »

nequo wrote: post #48
tome wrote: post #47

Earlier quoted context omitted.

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.

Re: Wasm_of_OCaml

#50

Post by tome »

abecedarius wrote: post #49
nequo wrote: post #48

Earlier quoted context omitted.

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
Post reply on HN