Ezjsonm.t is overly restrictive and not compliant with the spec

[dmbaturin]

#31 raises a valid question but doesn't go far enough. :)

Trying to parse Ezjsonm.from_string "1" should not throw any errors at all, it should return Float 1.0.

According to https://www.json.org/json-en.html , the start symbol of the grammar is "element" which is "whitespace? value whitespace?". This means bare primitive values like 1 or "hello world" are valid JSON.

That's also how most JSON libraries for other languages behave.

Another problem with the current approach is that if you are destructuring a JSON value, you cannot use to_string to to print a a value.

[dmbaturin]

Is anyone even maintaining the lib anymore? ;)

This is a specification compliance bug. I'm ready to work on a PR, but since it's a public interface change, I'd like to hear from the maintainers first.

[hhugo]

Ezjsonm.value_from_string "1" / Ezjsonm.value_to_string (`Float 1.) work as expected. I believe this can be closed.

[dmbaturin]

@hhugo No, you misunderstand my point. 1 or "hello world" are not only valid JSON values, they are also valid complete JSON documents.

Thus the function intended for parsing complete documents, Ezjsonm.from_string, also shouldn't fail on them.

[hhugo]

It seems ezjsonm follows an older version of the spec and makes a distinction between json document and json value. In https://tools.ietf.org/id/draft-ietf-json-rfc4627bis-01.xml, one can read

A JSON text is a serialized object or array.

JSON-text = object / array

Your are arguing that there is not such thing as a json document and that only json value matter. Is that your point ?

[jdh30]

I've spent quite a bit of time working on JSON parsing and serialization and have some comments.

To address the OP, as @hhugo says the pointless distinction between documents that had to be compound values and all other values was a design flaw in an old JSON specification that has since been fixed but obviously left many suboptimal APIs. Today there is no such distinction.

That's also how most JSON libraries for other languages behave.

I've tried dozens of different JSON libraries in various languages and, IME, they're mostly broken. So I recommend not appealing them as an authority. Two common mistakes I've seen are serializing dictionaries with arbitrary key types to JSON objects (that only work with string keys) and treating JSON numbers as ints or floats.

Trying to parse Ezjsonm.from_string "1" should not throw any errors at all, it should return Float 1.0.

I'm just looking at Ezjson for the first time and am concerned to see Float there. JSON has a number type that should not be confused with ints or floats. At the level of a JSON library, numbers should be treated as strings. Helper functions that convert to and from ints and floats might be useful but must be carefully written as JSON can represent arbitrary precision numbers and cannot represent the special floating point values negative infinity, negative zero, positive infinity and not-a-number. At the serialization layer you can convert ints to and from JSON numbers but floats need a richer representation such as either a JSON number or a JSON string containing some standard text such as neg_infinity or -Infinity or even -1/0. Different libraries and languages have their own weird and wonderful conventions.

HTH.