Just Microsoft's rebrand and restricted version of OCaml. And, imho, it is much better to use original language (since it have much more features), especially with Core library.
I mean, sure, you can use OCaml... unless you want/have to interop with .NET, then it doesn't matter how much you like OCaml, it's not going to solve your problem.
While F# was definitely strongly influenced by OCaml, their features have diverged significantly. For example, F# has type providers, active patterns, and units of measure (though you're also right that OCaml has lots of features that F# doesn't, like first class modules).
Note also that this blog post is about accepting contributions to the Visual Studio IDE components for F#, not for the language itself (which has been open source for many years, and has already been accepting contributions from the community for a little while).
No, not at all. It is true that units are erased at runtime, but the compile time behavior is quite sophisticated, going well beyond anything that's possible in C# or OCaml. (Your link is quite interesting, but I think that using a custom build step is "cheating" to some degree in that you can add arbitrary features by adding language-external post build processing).
By being built into the language, units of measure in F# work naturally with type inference (and definitions can be measure-generic), so:
let weirdOperation (x:float<_>) (y:float<_>) = x * x + y * y * y
"I think that using a custom build step is "cheating" to some degree in that you can add arbitrary features by adding language-external post build processing"
I guess, but: source code is still standard C#, it gives you pre-runtime static verification. As far as I understand Roslyn will support this kind of extensibility in a straightforward way. It is still better than unit testing same stuff in my opinion (except for specifying units in comments).
"By being built into the language" - do you mean F# code that uses units of measure wouldn't compile to OCAML (I am talking about simple compilability rather than proper support)?
It's very nice to be able to check annotations in a build step. I'm just saying that adding language-external checks makes it fairly meaningless to say that "C#" supports it; would it be fair to say that C# supports all of Haskell's features if I require annotating C# constructs with Haskell code and then use a modified Haskell compiler in a post-build step to verify that the pieces are composed in a valid way? None of this is to say that the C# code you linked to is not useful - it's just not possible to use "vanilla" C# to achieve what "vanilla" F# can do.
To your later question, while F# and OCaml share a common core, there's lots of F# code that won't compile as OCaml and vice versa, and units of measure are one such example. The syntax for measure-annotated types is not valid OCaml syntax.
i just want to note that as far as i've seen, the ocaml community has little to no animosity towards f#. there are lots of ML dialects out there and the prevailing mood seems to be one of cooperation rather than competition - it's nice to see people explore the design space.
Please tell us how much time would it take you to build an OCAML app that would target: web, Android, iOS, Mac, Linux, Windows (desktop, store, phone), PS4 etc.?
11 comments
[ 3.7 ms ] story [ 34.2 ms ] threadNote also that this blog post is about accepting contributions to the Visual Studio IDE components for F#, not for the language itself (which has been open source for many years, and has already been accepting contributions from the community for a little while).
I just learned that they could be implemented in C# relatively easily (although maybe not to same extent): http://www.codeproject.com/Articles/413750/Units-of-Measure-...
By being built into the language, units of measure in F# work naturally with type inference (and definitions can be measure-generic), so:
will be inferred to have typeI guess, but: source code is still standard C#, it gives you pre-runtime static verification. As far as I understand Roslyn will support this kind of extensibility in a straightforward way. It is still better than unit testing same stuff in my opinion (except for specifying units in comments).
"By being built into the language" - do you mean F# code that uses units of measure wouldn't compile to OCAML (I am talking about simple compilability rather than proper support)?
To your later question, while F# and OCaml share a common core, there's lots of F# code that won't compile as OCaml and vice versa, and units of measure are one such example. The syntax for measure-annotated types is not valid OCaml syntax.