[GSoC Proposal] Statically Checked Measurement Units

Cristi Cobzarenco cristi.cobzarenco at gmail.com
Tue Mar 29 02:29:39 PDT 2011


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.

To spir:
Calling the string representation a small domain specific language is
perfect. It is just that, a way of writing arithmetic expressions between
types - something we couldn't do inside D grammar. It's much like the lambda
definitions in functional. I too am queasy about using strings to represent
code, but I think that small DSLs that save effort and improve readability
is one place where it's OK.
Parsing the expressions at compile time will be fun, thankfully one only
needs a stack to do that (Djikstra's shunting yard algorithm) which very is
to implement in the functional-style metaprogramming land.

To David:
Using T.stringof, we can define a total order on types, based on their
typenames. I'm still thinking about conversion.

To Andrei and Jens:
std.datetime won't be simplified _that_ much, but it will probably require
some work so that it uses the same unit system as the future units library.
I would, of course, take care of this as well.

On 29 March 2011 09:06, Don <nospam at nospam.com> wrote:

> Cristi Cobzarenco wrote:
>
>> First, let me apologize for this very late entry, it's the end of
>> university and it's been a very busy period, I hope you will still consider
>> it.
>>
>> Note this email is best read using a fixed font.
>>
>> PS: I'm really sorry if this is the wrong mailing list to post and I hope
>> you'll forgive me if that's the case.
>>
>>
>> ======= Google Summer of Code Proposal: Statically Checked Units =======
>>
>>
>> Abstract
>> -------------
>>
>> Measurement units allow to statically check the correctness of assignments
>> and expressions at virtually no performance cost and very little extra
>> effort. When it comes to physics the advantages are obvious – if you try to
>> assign a force a variable measuring distance, you've most certainly got a
>> formula wrong somewhere along the way. Also, showing a sensor measurement in
>> gallons on a litre display that keeps track of the remaining fuel of a plane
>> (a big no-no) is easily avoidable with this technique. What this translates
>> is that one more of the many hidden assumptions in source code is made
>> visible: units naturally complement other contract checking techniques, like
>> assertions, invariants and the like. After all the unit that a value is
>> measured in is part of the contract.
>>
>
> This is one of those features that gets proposed frequently in multiple
> languages. It's a great example for metaprogramming. But, are there examples
> of this idea being seriously *used* in production code in ANY language?
> (For example, does anybody actually use Boost.Unit?)
>



-- 
(Cristi Cobzarenco)
Pofile: http://www.google.com/profiles/cristi.cobzarenco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110329/76264773/attachment-0001.html>


More information about the Digitalmars-d mailing list