Follow

Improductive rant here: my main complaint about is the need to write types both in the .ml and .mli, including module types (which are big). Is something better conceivable, though? No idea.

@otini Check out F#? It sands off a lot of the rough edges from OCaml.

@z I would be interested to check it out, but not yet interested enough to do it on my spare time, haha

@otini That's extremely fair. I have a similar feeling with Elixir.

@z
@otini
What advantages does F# have over OCaml? I asked around a couple times and the only answer I got was ".NET" but surely there's more to it than that.

@erkin @otini one difference that I am fond of is operator overloading so that you can just use '+' without having to have a special floating point version. I think it's a lot of little ergonomic things like that.

@erkin @z @otini .Net and... .Net. Also .Net Otherwise F# sacrifices the most interesting parts including the structural object system with object type inference and the entire module system to make the language interoperable with the rest of .Net

@otini I agree. I would have liked to have types that are not defined in the ml files to be implicitly imported from the mli file to the ml file. But that would add some kind of complexity to the language: I would understand that it seems superfluous.

One thing I do a lot is to have mli files with no implementation (with only types) for large structures. If there is any special operations on these, I just put them in a different module 😊

@otini Need to write types? I thought Hindley and Milner did something about it…

More seriously, I'm not a huge fan of the .mli files, mimicking the header files in C et al. I like more the SML's .sig files, holding the "module type", which the "modules" in the .sml files only refer to via :>.

Sign in to participate in the conversation
Functional Café

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!