## Wednesday, October 14, 2015

### Units in Wombat

The way I hope to do units in Wombat is something like this:

There will be a type for length/distance. There will be some predefined values of that type such as metre. If you want 3.0 metres it is 3.0*metre. If you have a distance and you want to write it out as a number, divide by metre: myDist/metre. The same for angles: π*radian=180*degree. It gets a bit ugly for temperatures: zeroC+30.0*cDeg, and ditto date-time.

To be more exact. Assume the numbers we are working with are type Approx. Units will live in a type U. So metre above should really be U.metre, but there is nothing to stop you declaring `metre=U.metre, etc. The Approx number live in U as a degenerate set of units, so when you do myDist/metre you actually end up with type U, not type Approx. However Approx isA U. So, either immediately or at any later time, we can convert our result to Approx without failing.

[Update: This is just because units exist where we have a torsor (http://math.ucr.edu/home/baez/torsors.html): the difference or ratio is a number, but there is no default scale (multiplicative) or no certain starting point (additive), and the two variants seem to often come together. At any rate it is obvious that we want to generalize this and have type U be just a special case of a wider torsor type.]

[Update 2: Wouldn't it be better to have each sort of quantity (distance, mass, time, etc) be a different type? Then the type system could sort everything out, and detect mistakes at compile time, and some things become more convenient (distance1/distance2 is automatically just a number). But there are an infinite number of combinations (mass/(distance**3) is density) so it would be a complex variety of indexed types. This is very typical of the hard choices between static and dynamic typing. Wombat's standard library will try to hit the middle, while allowing others to do very static or very dynamic stuff. In this case a Distance type may not need any additional properties compared to type U restricted to distance. If that is the case then the advantages of having Distance as a separate type can be realised in a simple way using subset types, that is also pretty easy for the programmer to understand, and which let's them go back to U for one-off stuff without having to create new types all the time.]