

Enabling Contributions to the Visual F# IDE Tools - pcj
http://blogs.msdn.com/b/somasegar/archive/2014/06/30/enabling-contributions-to-the-visual-f-ide-tools.aspx

======
kvb
It's an exciting time to be an F# programmer. The community really seems to be
stepping up and getting ready to make important contributions.

------
jackfoxy
For those interested in contributing to the F# language itself and the
compiler, the F# Open Engineering Group has an article on that topic
[http://fsharp.github.io/2014/06/18/fsharp-
contributions.html](http://fsharp.github.io/2014/06/18/fsharp-
contributions.html)

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

~~~
kvb
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
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-...](http://www.codeproject.com/Articles/413750/Units-of-Measure-
Validator-for-Csharp)

~~~
kvb
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
"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
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.

