Thanks for your answer!<div><br></div><div>- 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:</div>
<div><br></div><div>There is a type that determines the unit:</div><div>struct Meter {}</div><div><br></div><div>Then every quantity is parametrised with two aliases:</div><div>Quantity!(UnitList, ValueType)</div><div><br>
</div><div>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:</div><div>Quantity!( UnitList!( UnitPair!(Meter,1) ), double )</div>
<div><br></div><div>The strings are parsed at compile time and converted (using mixins) into the UnitList. For example:</div><div>ParseUnitString!("meters/second") -> UnitListDivison!( UnitList!( UnitPair!(Meter,1) ), UnitList!( UnitPair!(Second,1) ) ) -> UnitList( UnitPair!(Meter,1), UnitPair!(Second,-1) ).</div>
<div><br></div><div>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.</div>
<div><br></div><div> - The Categorical type sounds like a great idea. I think they could be passed on as a ValueType to a quantity:</div><div>typedef Quantity!(City, BoundedInt!(0,100)) CityID;</div><div><br></div><div>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.</div>
<div><br></div><div>What do you think?</div><div><br></div><div><br></div><div><br></div><div><br><br><div class="gmail_quote">On 28 March 2011 21:53, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:SeeWebsiteForEmail@erdani.org">SeeWebsiteForEmail@erdani.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On 3/28/11 10:43 AM, Cristi Cobzarenco wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
First, let me apologize for this very late entry, it's the end<br>
of university and it's been a very busy period, I hope you will still<br>
consider it.<br>
<br></div><div class="im">
Note this email is best read using a fixed font.<br>
<br>
PS: I'm really sorry if this is the wrong mailing list to post and I<br>
hope you'll forgive me if that's the case.<br>
<br>
======= Google Summer of Code Proposal: Statically Checked Units =======<br>
</div></blockquote>
[snip]<br>
<br>
This is a good place to discuss pre-submission proposals. To submit, go to <a href="http://d-programming-language.org/gsoc2011.html" target="_blank">http://d-programming-language.org/gsoc2011.html</a> later today.<br>
<br>
This is a strong draft proposal that I am likely to back up when complete. A few notes:<br>
<br>
* 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.<br>
<br>
* 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.<br>

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

<br>
* 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).<br>
<br>
* 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.<br>
<br>
<br>
Thanks for your interest, and good luck!<br><font color="#888888">
<br>
Andrei<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>(Cristi Cobzarenco)<br>Pofile: <a href="http://www.google.com/profiles/cristi.cobzarenco">http://www.google.com/profiles/cristi.cobzarenco</a><br>
</div>