{"action":"created","issue":{"url":"https://api.github.com/repos/bjornbm/dimensional/issues/110","labels_url":"https://api.github.com/repos/bjornbm/dimensional/issues/110/labels{/name}","comments_url":"https://api.github.com/repos/bjornbm/dimensional/issues/110/comments","events_url":"https://api.github.com/repos/bjornbm/dimensional/issues/110/events","html_url":"https://github.com/bjornbm/dimensional/issues/110","id":119828690,"number":110,"title":"One type to represent a Quantity with a given Unit?","user":{"login":"dmcclean","id":603347,"avatar_url":"https://avatars.githubusercontent.com/u/603347?v=3","gravatar_id":"","url":"https://api.github.com/users/dmcclean","html_url":"https://github.com/dmcclean","followers_url":"https://api.github.com/users/dmcclean/followers","following_url":"https://api.github.com/users/dmcclean/following{/other_user}","gists_url":"https://api.github.com/users/dmcclean/gists{/gist_id}","starred_url":"https://api.github.com/users/dmcclean/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dmcclean/subscriptions","organizations_url":"https://api.github.com/users/dmcclean/orgs","repos_url":"https://api.github.com/users/dmcclean/repos","events_url":"https://api.github.com/users/dmcclean/events{/privacy}","received_events_url":"https://api.github.com/users/dmcclean/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/bjornbm/dimensional/labels/enhancement","name":"enhancement","color":"84b6eb"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-12-01T23:03:23Z","updated_at":"2015-12-04T13:58:22Z","closed_at":null,"body":"Do we want to create a type that represents a `Quantity` represented in a specific `Unit`?\r\n\r\nIt'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.\r\n\r\nIt'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.\r\n\r\nFor 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.\r\n\r\nSimilarly, 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.\r\n\r\nI 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.\r\n\r\nAt present I think that this is a great idea on two conditions:\r\n\r\n1. It badly needs a name, preferably one that is in use elsewhere for the same concept.\r\n2. 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."},"comment":{"url":"https://api.github.com/repos/bjornbm/dimensional/issues/comments/161974141","html_url":"https://github.com/bjornbm/dimensional/issues/110#issuecomment-161974141","issue_url":"https://api.github.com/repos/bjornbm/dimensional/issues/110","id":161974141,"user":{"login":"bjornbm","id":37268,"avatar_url":"https://avatars.githubusercontent.com/u/37268?v=3","gravatar_id":"","url":"https://api.github.com/users/bjornbm","html_url":"https://github.com/bjornbm","followers_url":"https://api.github.com/users/bjornbm/followers","following_url":"https://api.github.com/users/bjornbm/following{/other_user}","gists_url":"https://api.github.com/users/bjornbm/gists{/gist_id}","starred_url":"https://api.github.com/users/bjornbm/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bjornbm/subscriptions","organizations_url":"https://api.github.com/users/bjornbm/orgs","repos_url":"https://api.github.com/users/bjornbm/repos","events_url":"https://api.github.com/users/bjornbm/events{/privacy}","received_events_url":"https://api.github.com/users/bjornbm/received_events","type":"User","site_admin":false},"created_at":"2015-12-04T13:58:22Z","updated_at":"2015-12-04T13:58:22Z","body":"I agree that those are better. I'll throw `ExpressedQuantity` into the mix too for you to consider.\n\n\n\n> On 3 dec 2015, at 23:56, Douglas McClean <notifications@github.com> wrote:\n> \n> 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.\n> \n> data PresentationQuantity d a = PresentationQuantity a (Unit 'NonMetric d a)\n>   deriving (Eq, Data, Generic, Typeable, ...)\n> —\n> Reply to this email directly or view it on GitHub.\n> \n"}}