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 <seewebsiteforem...@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