Enabling Contributions to the Visual F# IDE Tools

kvb 11 years ago | |

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

CmonDev 11 years ago | | |

Aren't units of measure just a compilation trick, leveraging the existing capabilities of OCAML (algebraic data types) and .NET (attributes)?

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

kvb 11 years ago | | |

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

will be inferred to have type

    x:float<'u ^ 3> -> y:float<'u ^ 2> -> float<'u ^ 6>

CmonDev 11 years ago | | |

"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)?

kvb 11 years ago | | |

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.

zem 11 years ago | |

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.

brandonbloom 11 years ago | |

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.

CmonDev 11 years ago | |

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