GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
The "units" primitive added at 3258647 doesn't behave the way I would like when it is nested within a model.
For example, in https://gist.github.com/4391674 I would like the object invoking the "size34_cutout" model to be able to use its own units environment independently of the invoked model. (I want a result like the picture above.)
Thinking more about units handling, I am suggesting we add a new data type for "physical-data" such as length. This data type is distinct from a float. Unit processing is performed during conversion between a float and a physical-data variable. Internally, a physical-data variable contains a float value in canonical units (mm is fine). It also contains a rational number representing the applicable exponent for the length units. This distinguishes area and volume data from length data.
Persons familiar with "dimensional analysis" http://en.wikipedia.org/wiki/Dimensional_analysis will recognize that this approach to physical-data types can be generalized to a very rich capability by adding additional exponents applying to mass, time, charge, and temperature. Such an approach allows elegant handling of mass properties (density, center of gravity, etc.) for example.
As suggested by the wikipedia citation, this may fit in with the current activity distinguishing affine points from vectors. The Siano orientation extension is new to me but looks intriguing. At a much simpler level, treating angular values as dimensioned (e.g. distinguishing radians from steradians) and integrating them into the units framework would provide a convenient, consistent way to support radians, degrees, and revolutions as alternative units of measure when converting to and from floats.
I know very little about Haskell but my impression is that this sort of data typing is right up its alley and could come out very elegantly.
There are several libraries for dimensioned values in haskell: http://www.haskell.org/haskellwiki/Physical_units
I haven't looked at them enough to evaluate them, much less thought through static vs. dynamic matching.