Various updates and compatibility with Aeson #58
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sometimes Aeson encodes maps as objects with string keys, or as `null`. We can now decode these cases.
Fix map decoding.
Adding encoders/decoders for Either.
Adding Data.BigInt support.
Adding a nix shell config, for repeatable dev envs.
It will now decode ints as well. Note that this is just us being more tolerant of recieving something like `1234`. If the number sent is actually in the "big" integer range (>2^32) then it won't work and it's the sender's fault. The JSON spec doesn't support numbers that big. They'd have to be sent as strings.
Instead of encoding them as strings, we use numbers. 'Improved' is somewhat subjective here. More likely to be successfully read and written, perhaps less likely to be correct in all cases. Sadly I don't see a good alternative short of forking all the consuming libraries too.
Since we no longer care about introducing a dependency on test-unit, let's tidy up the ad-hoc test framework.
The motivation for this is JSON parsing. In order to correctly parse big integers from JSON, we need use a custom parser. The `JSON.parse` builtin won't do.
And adding tests.
Sometimes Aeson encodes maps as objects with string keys, or as `null`. We can now decode these cases.
It will now decode ints as well. Note that this is just us being more tolerant of recieving something like `1234`. If the number sent is actually in the "big" integer range (>2^32) then it won't work and it's the sender's fault. The JSON spec doesn't support numbers that big. They'd have to be sent as strings.
Instead of encoding them as strings, we use numbers. 'Improved' is somewhat subjective here. More likely to be successfully read and written, perhaps less likely to be correct in all cases. Sadly I don't see a good alternative short of forking all the consuming libraries too.
Since we no longer care about introducing a dependency on test-unit, let's tidy up the ad-hoc test framework.
The motivation for this is JSON parsing. In order to correctly parse big integers from JSON, we need use a custom parser. The `JSON.parse` builtin won't do.
And adding tests.
Rebase upstream
Closed
|
Is anybody moving this forward? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
So sorry that this is all a bit of a mix but I want to get a PR open (in place of #52 which I am closing) with everything we have done in our fork to see if it's possible to get things upstreamed. I.e. which things here would you not be willing to upstream? Mostly this is around compatibility with Aeson and common data types.
Other things: