-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom JSON parsing #115
Custom JSON parsing #115
Conversation
This'll unblock a few limitations relating to Aeson as a library. Additionally it enables interop with the ICU message parser. As of this commit multiple errors is broken, however printed error metadata is substantially improved for free.
This time with file/line metadata!
For additional confidence given this is a big diff, I've run this against everything in Unsplash web and there are no errors. Inserted errors are caught. |
Note to self: Add some end-to-end tests for multiple error reporting across different parser error types (keys, ICU, etc). Context: #114 (comment) |
To help subparsers prevent parsing beyond the bounds of the message in JSON.
@OliverJAsh Your suggestion for further tests caught two bugs with error reporting! One new and one preexisting. 😎 |
Depends #114.
Whilst implementing our own JSON parser seems a bit wild, we don't really need a full JSON parser on account of our input following a fairly rigid schema. This is mirrored in the relative simplicity of the added parser. And it gives us a great deal of flexibility, enabling as of this PR:
As with #114, both of the key error types are recoverable, and this recovery interoperates with other recoverable errors such as in message parsing. Note that failing to parse JSON is generally not recoverable.
Thus, given via
intlc compile -l foo ./x-all.json
:Before:
After:
Detaching ourselves from Aeson decoding suggests we could and should implement our own encoder, which is really just going to be another "compiler" in the spirit of those we already have. This would solve our inability to pretty print flattened JSON output.
I'd additionally like to slightly modify the error output to include an additional line or two of context so that the offending key is visible (#116). Further refinements could also be made to various (sub)parsers to improve error output legibility.