[GSoC Proposal] Statically Checked Measurement Units

[David Nadlinger]

On 3/29/11 3:49 PM, Cristi Cobzarenco wrote:
> To David:
> Ok, right now, I got two working versions, one sorting by .mangleof and
> one performing a double-inclusion test on the tuples. Both work, I can't
> see any performance increase in the .mangleof one, but if .mangleof
> returns unique string, I say we use it this way.

To be honest, I still don't see how you are able to get away without 
canonicalization in the first place; would you mind to elaborate on how 
you solve the issue of different ordering of expression yielding types? 
This is not about the algorithm to determine whether two types are 
semantically equivalent, where your algorithm would work fine as well, 
but about the actual D types. If you don't sort them, 
Quantity!(BaseUnitExp!(Meter, 1), BaseUnitExp!(Second, -2)) and 
Quantity!(BaseUnitExp!(Second, -2), BaseUnitExp!(Meter, 1)) would be 
different types, which is not desirable for obvious reasons.


> Regarding my string little DSL. I have 3 solutions right now:
> 1. Drop the DSL altogether, right now my system would work perfectly
> fine with boost-like tuples (a list of units alternating with exponents):
> Quantity!(Metre,1,Second,-1) speed = distance/time;
> While less readable, this doesn't have the disadvantages of the following 2.
>
> 2. Use a mixin template to declare the expression parser in the current
> scope:
> mixin DeclareExprQuantity!();
>
> struct Metre {}
> struct Second {}
> struct Kg {}
>
> void f() {
>         ExprQuantity!("Metre/Second * Kg^-1") q = speed / mass;
> }
> This works, is readable, but it uses C-preprocessor like behaviour
> (read: black vodoo) - a library declaring something in your scope isn't
> very nice.
>
> […]
>
> The only completely clean alternative would be the abominable:
> Quantity!( mixin(Expr!("Metre/Second")) ) q;

Get out of my head! Immediately! ;) Just kidding – incidentally I 
considered exactly the same options when designing my current prototype. 
My current approach would be a mix between 1 and 2: I don't think the 
Boost approach of using »dummy« instances of units is any less readable 
than your proposed one when you don't deal with a lot of units. For 
example, consider

enum widgetCount = quantity!("Widget")(2);
vs.
enum widgetCount = 2 * widgets;

This could also be extended to type definitions to avoid having to 
manually write the template instantiation:

Quantity!("meter / second", float) speed;
vs.
typeof(1.f * meter / second) speed;

There are situations, though, where using unit strings could 
considerable improve readability, namely when using lots of units with 
exponents. In these cases, a mixin could be used to bring all the types 
in scope for the »parsing template«, similar to the one you suggested. 
If a user of the library things  could use an additional mixin 
identifier to clarify the code, e.g. »mixin UnitStringParser U; […] 
U.unit!"m/s"«).

But a more attractive solution would exploit the fact that you would 
mostly use units with a lot of exponents when working with a »closed« 
unit system without the need for ad-hoc extensions, like the SI system, 
which would allow you to use unit symbols instead of the full name, 
which wouldn't need to be globally unique and wouldn't pollute the 
namespace (directly defining a type »m« to express meters would probably 
render the module unusable without static imports).

It would essentially work by instantiating a parser template with all 
the named units. Thus, the parser would know all the types and could 
query them for additional properties like short names/symbols, etc. In code:

---
module units.si;
[…]
alias UnitSystem!(Meter, Second, …) Si;
---
module client;
import units.si;
auto inductance = 5.0 * Si.u!"m^2 kg/(s^2 A^2)";
---

This could also be combined with the mixin parser approach like this:
---
import units.si;
mixin UnitStringParser!(Si) U;
---

But to reiterate my point, I don't think a way to parse unit strings is 
terribly important, at least not if it isn't coupled with other things 
like the ability to add shorthand symbols.

David