[GSoC Proposal] Statically Checked Measurement Units

[Don]

Cristi Cobzarenco wrote:
> To Don:
> That is a very good point and I agree that one shouldn't implement 
> features just because they're popular. There don't seem to be many (if 
> any projects) using Boost.Units and only a few that use the feature in F#.
> But, I think the reason Boost.Units isn't use hasn't got much to do with 
> the idea as much as it does with the implementation. Using units in 
> Boost is very cumbersome. Adding new units (measuring different 
> dimensions) on-the-fly is virtually impossible. I think that that 
> Boost.Units misses the point of units. They should be a natural 
> extension of the type system of a language, not something so limited to 
> the area of natural sciences. D is a new language and we should be 
> pushing the envelope, just because the Boost failed (if it did, it may 
> very well kick-off later) doesn't mean we shouldn't do it. Since it is 
> such a new feature, I think we should talk about its potential rather 
> than its acceptance.
> When it comes to F#, I think the reason there aren't many projects using 
> units is because there aren't many projects in F# period. It is a very 
> popular feature in the F# community (judging by blog posts and the like) 
> and people are still trying to figure out exactly how to use it. I feel 
> that in F#, it has the potential to become very widely used once people 
> agree on some conventions and good practices.
> As I said in the abstract, I think the feature fits snugly with other 
> mechanisms in D and seems to be a natural part of a contract-based 
> design, so D programmers should have a predisposition (that C++ 
> programmers might not have) of adopting such a feature.
> 
> I really hope this doesn't come off as rude; as I said, you make a very 
> good point, one that needs answering. I guess what I'm saying can be 
> summed up as: it is a new feature; there have been mistakes; it has a 
> lot of potential and we can make it better. I'd be curious to hear what 
> you think.

I'm a physicist and most of my programming involves quantities which 
have units. Yet, I can't really imagine myself using a units library. A 
few observations from my own code:
* For each dimension, choose a unit, and use it throughout the code. For 
example, my code always uses mm because it's a natural size for the work 
I do. Mixing (say) cm and m is always a design mistake. Scaling should 
happen only at input and output, not in internal calculations. (So my 
feeling is, that the value of a units library would come from keeping 
track of dimension rather than scale).
* Most errors involving units can, in my experience, easily be flushed 
out with a couple of unit tests. This is particularly true of scale 
errors. The important use cases would be situations where that isn't true.
* Arrays are very important. Although an example may have force = mass * 
accelaration, in real code mass won't be a double, it'll be an array of 
doubles.

 > Since it is
 > such a new feature, I think we should talk about its potential rather
 > than its acceptance.

I'm really glad you've said that. It's important to be clear that doing 
a perfect job on this project does not necessarily mean that we end up 
with a widely used library. You might be right that the implementations 
have held back widespread use -- I just see a significant risk that we 
end up with an elegant, well written library that never gets used.
If the author is aware of that risk, it's OK. If not, it would be a very 
depressing thing to discover after the project was completed.