One type to represent a Quantity with a given Unit?

[dmcclean]

Do we want to create a type that represents a Quantity represented in a specific Unit?

It's quite clear that having Quantity track only dimension and not unit is the correct design decision for uses of Quantity that involve actual computing and have actual physical meaning.

It's less clear to me that we shouldn't also have a type pairing the two for use in user interfaces and perhaps in logs. For expository purposes let such a type be named UQ :: Dimension -> * -> * since I don't know what to call it yet.

For example, the user input "3.7 feet" could usefully be parsed to a value of type UQ DLength Scientific before ultimately being converted to a Length Double and passed to some physics code. This value would have the virtue of exactly preserving the data as given, which could be important e.g. for traceability.

Similarly, on the output side, code that decides on display conventions for units and precision could convert a Length Double to a UQ DLength Scientific before being passed to lower level code that converts it to a String, Text, JSON, some HTML type, or whatever.

I came to this idea because the UCUM grammar allows arbitrary decimal factors to appear in "units". We don't support that and probably don't want to. So perhaps our parser should return AnyUQ ExactPi instead of AnyQuantity ExactPi or AnyUnit. This would preserve whatever information we have about how the value was given, but would also offer sensible encodings for these factors.

At present I think that this is a great idea on two conditions:

1. It badly needs a name, preferably one that is in use elsewhere for the same concept.
2. We need to be able to document it in such a way as to clearly indicate that this is not the type you should be passing around within your core system.

[dmcclean]

Other possible names include Measurement, Observation, WrittenQuantity, SerializedQuantity, ExpressedQuantity. I'm not sold on any of these.

[dmcclean]

I rather like PresentationQuantity or PresentedQuantity. It doesn't carry the same baggage about who is presenting to whom (it works for both input and output scenarios) and doesn't imply that it was a measurement when in fact it might be the presentation form of a calculated result.

data PresentationQuantity d a = PresentationQuantity a (Unit 'NonMetric d a)
  deriving (Eq, Data, Generic, Typeable, ...)

[bjornbm]

I agree that those are better. I'll throw ExpressedQuantity into the mix too for you to consider.

On 3 dec 2015, at 23:56, Douglas McClean notifications@github.com wrote:

I rather like PresentationQuantity or PresentedQuantity. It doesn't carry the same baggage about who is presenting to whom (it works for both input and output scenarios) and doesn't imply that it was a measurement when in fact it might be the presentation form of a calculated result.

data PresentationQuantity d a = PresentationQuantity a (Unit 'NonMetric d a)
deriving (Eq, Data, Generic, Typeable, ...)
—
Reply to this email directly or view it on GitHub.

[dmcclean]

It now occurs to me based on the name PresentationQuantity that this is also the way to model #82, I think. The rounding happens during the conversion to a PresentationQuantity and not during the showing of the presentation quantity, and so that's when you have an opportunity to round the arcseconds or inches or whatever up to the value that will cause a rollover.