{"action":"created","issue":{"url":"https://api.github.com/repos/bos/aeson/issues/546","repository_url":"https://api.github.com/repos/bos/aeson","labels_url":"https://api.github.com/repos/bos/aeson/issues/546/labels{/name}","comments_url":"https://api.github.com/repos/bos/aeson/issues/546/comments","events_url":"https://api.github.com/repos/bos/aeson/issues/546/events","html_url":"https://github.com/bos/aeson/issues/546","id":226767955,"node_id":"MDU6SXNzdWUyMjY3Njc5NTU=","number":546,"title":"Should we make a clear value-level distinction between floating and integral numbers?","user":{"login":"leftaroundabout","id":1528675,"node_id":"MDQ6VXNlcjE1Mjg2NzU=","avatar_url":"https://avatars2.githubusercontent.com/u/1528675?v=4","gravatar_id":"","url":"https://api.github.com/users/leftaroundabout","html_url":"https://github.com/leftaroundabout","followers_url":"https://api.github.com/users/leftaroundabout/followers","following_url":"https://api.github.com/users/leftaroundabout/following{/other_user}","gists_url":"https://api.github.com/users/leftaroundabout/gists{/gist_id}","starred_url":"https://api.github.com/users/leftaroundabout/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/leftaroundabout/subscriptions","organizations_url":"https://api.github.com/users/leftaroundabout/orgs","repos_url":"https://api.github.com/users/leftaroundabout/repos","events_url":"https://api.github.com/users/leftaroundabout/events{/privacy}","received_events_url":"https://api.github.com/users/leftaroundabout/received_events","type":"User","site_admin":false},"labels":[{"id":315555511,"node_id":"MDU6TGFiZWwzMTU1NTU1MTE=","url":"https://api.github.com/repos/bos/aeson/labels/question","name":"question","color":"5319e7","default":true}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":29,"created_at":"2017-05-06T12:49:30Z","updated_at":"2019-01-03T08:56:15Z","closed_at":null,"author_association":"NONE","body":"This basic subject has been variously discussed before –\r\n\r\nhttps://github.com/bos/aeson/issues/227\r\nhttps://github.com/bos/aeson/issues/181\r\n\r\nThe thing is that Aeson can't make a distinction between integer values and floating-point values (scientific values) which merely happen to be equal to an integer.\r\n```\r\nPrelude Data.Aeson> encode 4\r\n\"4\"\r\nPrelude Data.Aeson> encode 4.0\r\n\"4\"\r\nPrelude Data.Aeson> encode 4e+30\r\n\"4000000000000000000000000000000\"\r\nPrelude Data.Aeson> encode 4.53986e+30\r\n\"4539860000000000000000000000000\"\r\n```\r\nThe former two may be sensible enough. The latter are kinda _correct_ too, at least in a dynamically-typed understanding of numbers; but they're arguably not desirable. It's most obvious when interpreting JSON as a human-readable format, as the [aeson-pretty](http://hackage.haskell.org/package/aeson-pretty) library does. There, this behaviour [is under discussion right now](https://github.com/informatikr/aeson-pretty/issues/22). In science, numbers like `4.53986e+30` are very much not something unusual, and nobody would consider it acceptable to print them in expanded, exact integer form if the purpose is human readability.\r\n\r\nNow, it's understood that Aeson itself does _not_ really focus on human readability, but even so, such insignificant-digit-monsters are a bit of a pain. The space usage and parsing overhead can't be completely irrelevant.\r\n\r\nDynamic languages like Python actually make a distinction between integers and integral-floats in JSON:\r\n```python\r\nPython 3.4.3 (default, Nov 17 2016, 01:08:31) \r\nType \"copyright\", \"credits\" or \"license\" for more information.\r\n\r\nIPython 4.0.1 -- An enhanced Interactive Python.\r\n?         -> Introduction and overview of IPython's features.\r\n%quickref -> Quick reference.\r\nhelp      -> Python's own help system.\r\nobject?   -> Details about 'object', use 'object??' for extra details.\r\n\r\nIn [1]: import json\r\n\r\nIn [5]: json.dumps(4)\r\nOut[5]: '4'\r\n\r\nIn [6]: json.dumps(4.0)\r\nOut[6]: '4.0'\r\n\r\nIn [7]: json.dumps(4e+32)\r\nOut[7]: '4e+32'\r\n```\r\n\r\nAeson used to have such a distinction too: before aeson-0.7, `Number` used [`Data.Attoparsec.Number`](http://hackage.haskell.org/package/attoparsec-0.10.4.0/docs/Data-Attoparsec-Number.html#t:Number), which has separate cases. Now granted, this can lead to some problems too\r\n\r\nhttps://github.com/sol/aeson-qq/issues/4\r\n\r\nbut I think all in all I think we should follow Python here. So would it be viable to try something like\r\n```haskell\r\ndata Value = Object !Object\r\n           | Array !Array\r\n           | String !Text\r\n           | Scientific !Scientific\r\n           | Int !Int\r\n           | Bool !Bool\r\n           | Null\r\n             deriving (Eq, Read, Show, Typeable, Data)\r\n```\r\nto have a clear grasp of which numbers are really integers and which ones are merely _within experimental error in the range of an integer_?"},"comment":{"url":"https://api.github.com/repos/bos/aeson/issues/comments/451084857","html_url":"https://github.com/bos/aeson/issues/546#issuecomment-451084857","issue_url":"https://api.github.com/repos/bos/aeson/issues/546","id":451084857,"node_id":"MDEyOklzc3VlQ29tbWVudDQ1MTA4NDg1Nw==","user":{"login":"phadej","id":51087,"node_id":"MDQ6VXNlcjUxMDg3","avatar_url":"https://avatars2.githubusercontent.com/u/51087?v=4","gravatar_id":"","url":"https://api.github.com/users/phadej","html_url":"https://github.com/phadej","followers_url":"https://api.github.com/users/phadej/followers","following_url":"https://api.github.com/users/phadej/following{/other_user}","gists_url":"https://api.github.com/users/phadej/gists{/gist_id}","starred_url":"https://api.github.com/users/phadej/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/phadej/subscriptions","organizations_url":"https://api.github.com/users/phadej/orgs","repos_url":"https://api.github.com/users/phadej/repos","events_url":"https://api.github.com/users/phadej/events{/privacy}","received_events_url":"https://api.github.com/users/phadej/received_events","type":"User","site_admin":false},"created_at":"2019-01-03T08:56:15Z","updated_at":"2019-01-03T08:56:15Z","author_association":"CONTRIBUTOR","body":"I'm tired of arguing.\n- What `Scientific 1 == Int 1` would be, I see here more new problems than this change would help.\n- Actually: please make a patch, and try to port few aeson dependencies (e.g. lens-aeson, github). It might all turn out great, or will be clearly bad, or something in between. Anyway, the patch would bring something constructive to the discussion.\n\nSent from my iPhone\n\n> On 3 Jan 2019, at 10.19, Antonio Nikishaev <notifications@github.com> wrote:\n> \n> @phadej,\n> \n> So we cannot encode big Integers in scientific format, because it will break interoperability with Python.\n> \n> But it's already broken\n> \n> >>> json.dumps(json.loads('10')), json.dumps(json.loads('1.0e1'))\n> ('10', '10.0')\n> λ> encode . decode @Value <$> [\"10\", \"1.0e1\"]\n> [\"10\",\"10\"]\n> —\n> You are receiving this because you were mentioned.\n> Reply to this email directly, view it on GitHub, or mute the thread.\n"}}
{"actor":{"display_login":"phadej"}}