[GSoC Proposal] Statically Checked Measurement Units

[Cristi Cobzarenco]

Thanks for your answer!

- I agree that using strings to represent units is not a particularly good
idea. Since many people have noted related things, I seem not to have been
particularly clear about the way I intend to use strings. Let me try to
explain it in detail:

There is a type that determines the unit:
struct Meter {}

Then every quantity is parametrised with two aliases:
Quantity!(UnitList, ValueType)

UnitList represents a list of pairs (UnitType,Exponent), where UnitType is a
typename (like Meter) and Exponent is a static rational type. Therefore, the
following would be a valid quantity type:
Quantity!( UnitList!( UnitPair!(Meter,1) ), double )

The strings are parsed at compile time and converted (using mixins) into the
UnitList. For example:
ParseUnitString!("meters/second") -> UnitListDivison!( UnitList!(
UnitPair!(Meter,1) ), UnitList!( UnitPair!(Second,1) ) ) -> UnitList(
UnitPair!(Meter,1), UnitPair!(Second,-1) ).

Therefore there is no need to convert all strings to a cannonical form, they
are all converted to an alias tuple (UnitList). To check whether two
UnitList's are the same, one can check double-inclusion. What do you think,
does this make sense.

 - The Categorical type sounds like a great idea. I think they could be
passed on as a ValueType to a quantity:
typedef Quantity!(City, BoundedInt!(0,100)) CityID;

And BoundedInt is just a type implicitly-convertible to and from int, that
supports assignment and equality and throws on an out-of-bounds assignment.

What do you think?





On 28 March 2011 21:53, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org>wrote:

> On 3/28/11 10:43 AM, 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 =======
>>
> [snip]
>
> This is a good place to discuss pre-submission proposals. To submit, go to
> http://d-programming-language.org/gsoc2011.html later today.
>
> This is a strong draft proposal that I am likely to back up when complete.
> A few notes:
>
> * There is a good overview of existing work, which puts the proponent in
> the right position to make the best choices for an implementation in D.
>
> * Human-readable strings as means to generate types is a fertile direction.
> One issue is canonicalization, e.g. "meters^2" would be a different type
> from "meters ^ 2" (and btw that should mimic D's operators, so it should use
> "^^"), and both are different from the semantically equivalent
> "meters*meters". I think this is avoidable by a function that brings all
> strings to a canonical form. This needs to be discussed in the proposal.
>
> * The approach to quantities of discrete objects (widgets, gadgets and I
> hope to see examples with degrees, radians etc.) is very promising. I'm also
> looking forward to a "Categorical" type - an integer-based quantity that
> describes a bounded enumeration of objects, for example "CityID".
> Categorical measures are not supposed to support arithmetic; they simply
> identify distinct objects in an unrelated space.
>
> * In the final proposal the scope of the library should be clarified (e.g.
> what kinds of units and related idioms will be supported, and what kinds you
> chose not to support and why).
>
> * At best the proposal could define and project a relationship with
> std.datetime, which defines a few units itself. Wonder whether it's possible
> to simplify std.datetime by using the future units library.
>
>
> Thanks for your interest, and good luck!
>
> Andrei
>



-- 
(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/20110328/9cafe170/attachment-0001.html>