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
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
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.
Having taken a quick cursory look at the new JSON5 module, I think it would make sense to have a distinct decoder for JSON5, but have common code for the encoder. Having decode() and validate() call the appropriate implementation depending on flags. This would reduce the amount of code duplication, and ensure that the flags used by the modules stay compatible.
/grubba
Sigh. I didn’t intend to push that code yet (nor push it directly onto 8.1). Sorry about that.
I agree that it makes sense for the encoder to be common, as I can’t see how a separate encoder would be helpful, unless you’d want to include comments or prefer a certain style unavailable in JSON proper.
The only argument I can think of against your suggestion would be one of discoverability… If JSON5 decoding were enabled via a flag, you’d need to know to look for it whereas most other implementations are in distinct namespaces (partly due to the fact that they’re all independent implementations). Could JSON5.encode() just be an alias for JSON.encode()? Then no flags would be required at all…
Bill
On Dec 23, 2017, at 10:37 AM, Henrik Grubbström (Lysator) @ Pike (-) developers forum 10353@lyskom.lysator.liu.se 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.
Having taken a quick cursory look at the new JSON5 module, I think it would make sense to have a distinct decoder for JSON5, but have common code for the encoder. Having decode() and validate() call the appropriate implementation depending on flags. This would reduce the amount of code duplication, and ensure that the flags used by the modules stay compatible.
/grubba
Having taken a quick cursory look at the new JSON5 module, I think it would make sense to have a distinct decoder for JSON5, but have common code for the encoder. Having decode() and validate() call the appropriate implementation depending on flags. This would reduce the amount of code duplication, and ensure that the flags used by the modules stay compatible.
I think it makes sense to have JSON and JSON5 exposed as different modules, since presumably you know which version of JSON you are processing. In JSON5 you can encode more compact than JSON, and there is support for inf/nan, so you want different encoder behaviour.
(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
pike-devel@lists.lysator.liu.se
-
Arne Goedeke -
H. William Welliver III -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Martin Nilsson (Coppermist) ＠ Pike (-) developers forum
-
Stephen R. van den Berg