Live data from Hacker News

Enabling Contributions to the Visual F# IDE Tools

blogs.msdn.com

11–12 of 12 posts

Re: Enabling Contributions to the Visual F# IDE Tools

#11
post #10
post #8

Earlier quoted context omitted.

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

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…

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

Re: Enabling Contributions to the Visual F# IDE Tools

#12
post #11
post #10

Earlier quoted context omitted.

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…

"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 f…

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.

Post reply on HN