Retire variants?

[bjornbm]

#2 started out being mostly about removing the distinction between quantities and units. I was reluctant then, saying:

Separating units and quantities was a very conscious decision, and one that I am quite happy with and feel has worked quite well in practice (YMMV). Converting quantities to values is performed, by necessity, very close to NIST guidelines (see 7.1 and 7.8) and I think this is a good thing.

Now, in light of e.g. #38, I'm reconsidering. Perhaps the added complexity of separating 'Quantity' and 'Unit' is not worth the extra complexity (Variant phantom type) and occasionally convoluted workarounds (e.g. Prelude. uses) that it can cause.

Relaxing would allow some ugly stuff:

x = kilo (meter + mile)
y = second * x

But even the current design isn't perfect with regards to NIST, allowing, e.g.:

u = kilo (kilo (meter / second))

so I'm not sure it is worth defending.

I would like to hear if you, Doug, have had any more thoughts on this topic. I know that you have actually gone even further with the distinction in the named-units branch, and imagine the impact would be treating everything as a unit (i.e. keep tracking the unit name) until multiplying with a Num (e.g. with (*~)).

[dmcclean]

I really like the named-units approach. It has some really nice benefits for programs that interface with humans. I like the easy tracking of preferred units for each named signal in the FRP program.

Even the kilo (kilo (meter / second)) this is addresed with the Atomic / Composite thing, except that atomic and composite are fairly bad names. They are bad names because the standard does like kilo (meter / second) and because it doesn't like kilo inch and section 7.10.1 doesn't like prefixes on the unit one. Prefixable / NotPrefixable might be better names. Using the type-level True and False is another option.

[dmcclean]

Closing this as adequately and more comprehensively discussed under #46 and #48.