[GSoC Proposal] Statically Checked Measurement Units

[Andrei Alexandrescu]

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