(this is a bit after the fact since I’ve already started to push code…)
Agreed. I copied the existing code and made the modifications for the JSON5 additions to a new module.
I’ve never used ragel before, but after getting up to speed, I’ve enjoyed the process. The only problem I was left with was a single line comment at the end of a file without a new line (technically invalid, but possible). The obvious solution caused ragel to go into an infinite loop trying to generate c code and I wasn’t able to figure out a good solution by using an EOF action. So, I left things with a fairly strict interpretation of the spec.
One thing I’m wondering about is the -Infinity, +NaN and -NaN symbols. I can use Int.Inf, but the rest don’t seem to have an equivalent in Pike… would it make sense to add those?
Bill
On Dec 21, 2017, at 9:33 AM, Arne Goedeke el@laramies.com wrote:
I think adding a new module would be easier. The JSON5 format is very permissive and would add many new rules (e.g. identifiers as object keys). I think a new parser (maybe copied from the existing JSON parser) would make it easier to adjust the grammar. I am not sure if you like ragel, but I found it to be very pleasant to work with.
Arne
On 12/20/17 23:28, H. William Welliver III wrote:
I was thinking that it might be nice to support parsing JSON5[1] documents (and a few of the additions, such as trailing commas in arrays and objects already seem to work). My initial thought before looking at Standards.JSON was that the additional feature support would be enabled by a flag to Standards.JSON.decode(). After looking at the ragel parser and the differences in the grammar, I'm wondering if it might be better to just create a new parser for JSON5. I suppose it would be possible to use a feature flag to select the parser but the overall architecture question remains.
Any thoughts?
Bill
[1] http://json5.org