Hello, On , Mattias Andrée wrote: > Wouldn't it just complicate matters if you needed to specify whether a > number is an integer or a real value;
Could you not just consider sequence of [0-9]+ to be an integer and anything with other characters either invalid or float? Not sure, I'm in no means a parser expert, so I might be missing something fundamental here. > Additionally, I think you would want to support for arbitrary > precision. Again, the software can just check if arbitrary precision > is required, no need to complicate the syntax. Agreed, arbitrary precision would be nice, and currently is probably done via strings if it's needed. But not sure if it's something you want to have in the standard though as a separate type. Passing them via string is probably good enough for specialized applications that do need them. > What should a library do with parsed numbers that are too large or too > precise? Report an error and provide flag to do best-possible parsing if user wants the number anyway knowing it will not be precise. Not do a silent guesstimate. Basically, I think the fact that following returns false is stupid: + $ ruby -rjson -e 'puts({ num: (?9 * 100).to_i }.to_json)' \ | node -p 'var fs = require("fs"); JSON.stringify(JSON.parse(fs.readFileSync(0, "utf-8")));' \ | ruby -rjson -e 'puts (?9 * 100).to_i == JSON.parse(STDIN.read)["num"]' false That means that despite all libraries in the chain fully implementing the JSON standard, not silently corrupting the data during the round-trip is not guaranteed. W. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
signature.asc
Description: PGP signature