6 ms·

F# Units of Measure – A Worked Example

77 points by numo16 12y ago

bsaul 12y ago
I could easily imagine a language extension that would automatically create "companion" number types for any other type ( you create a type "animal" and you automically get a "number of animals" unit of measure type. This way you would almost never have "raw" int or float types.
- andrewchambers 12y ago
  I'm pretty sure type providers can do that.
RobotCaleb 12y ago
This is neat stuff, and I've looked into it before. One question I have, though, is regarding interoperability with C#. If I have a units library that is in F# using what's shown in OP, would I be able to use the UoM in C#, or would I have to revert to unitless values on the C# side of the interface?
- RobotCaleb 12y ago
  A little bit of searching shows that this is entirely in the compiler and the CLR never sees it. I did find an exploration of this topic at https://stackoverflow.com/questions/348853/units-of-measure-in-c-sharp-almost https://stackoverflow.com/questions/348853/units-of-measure-...
- ghuntley 12y ago
  From the article @ "Units of Measure at runtime and interoperability ": One key point to take heed of, is that units of measure do not exist at runtime. They are intended for static type checking only and therefore prevent us implementing functionality based on checking units. They are also not part of the wider .NET type system and can therefore not be consumed, or used, by any non F# assembly. If exposing units of measure to consumers, the units are simply not visible and all values will be treated as there underlying, dimensionless type.
  - M8 12y ago
    Yes, that's the biggest problem with them.
jamez1 12y ago
Every language should have this. Simple idea but it makes so much sense.
jug 12y ago
F# is perfect for a part of our application, I just dislike that we can't mix .NET languages within the same Visual Studio project without going through hoops. I had expected this to have been solved by now since they all compile down to IL anyway. Hmm, maybe we'll just have to put it in a separate project even if it feels silly to just have a few classes there, which in turn are strongly related to others. It just feels so perfect for these particular classes.

77 points by numo16 12y ago

bsaul 12y ago

I could easily imagine a language extension that would automatically create "companion" number types for any other type ( you create a type "animal" and you automically get a "number of animals" unit of measure type. This way you would almost never have "raw" int or float types.

andrewchambers 12y ago
I'm pretty sure type providers can do that.

RobotCaleb 12y ago

This is neat stuff, and I've looked into it before. One question I have, though, is regarding interoperability with C#. If I have a units library that is in F# using what's shown in OP, would I be able to use the UoM in C#, or would I have to revert to unitless values on the C# side of the interface?

RobotCaleb 12y ago
A little bit of searching shows that this is entirely in the compiler and the CLR never sees it. I did find an exploration of this topic at https://stackoverflow.com/questions/348853/units-of-measure-in-c-sharp-almost https://stackoverflow.com/questions/348853/units-of-measure-...
ghuntley 12y ago
From the article @ "Units of Measure at runtime and interoperability ": One key point to take heed of, is that units of measure do not exist at runtime. They are intended for static type checking only and therefore prevent us implementing functionality based on checking units. They are also not part of the wider .NET type system and can therefore not be consumed, or used, by any non F# assembly. If exposing units of measure to consumers, the units are simply not visible and all values will be treated as there underlying, dimensionless type.
- M8 12y ago
  Yes, that's the biggest problem with them.

jamez1 12y ago

Every language should have this. Simple idea but it makes so much sense.

jug 12y ago

F# is perfect for a part of our application, I just dislike that we can't mix .NET languages within the same Visual Studio project without going through hoops. I had expected this to have been solved by now since they all compile down to IL anyway. Hmm, maybe we'll just have to put it in a separate project even if it feels silly to just have a few classes there, which in turn are strongly related to others. It just feels so perfect for these particular classes.