[eeps] Revision of the JSON EEP

[David-Sarah Hopwood]

Richard A. O'Keefe wrote:
> I should have waited until I'd read Saturday's mail,
> Sunday's mail, and Monday's mail as well.  Sigh.
> Here is the THIRD draft.
> 
> ------------------------------------------------------------------------

         A number is converted to an Erlang float if
         - it contains a decimal point, or
         - it contains an exponent, or
         - the option {float,true} was passed.
         A JSON number that looks like an integer will be converted to
         an Erlang integer unless {float,true} was provided.

This represents equivalent JavaScript numbers (for example, "1e1" and "10")
as different Erlang terms, i.e. which Erlang term is used can depend on
the JSON encoder. Also, it cannot round-trip "-0", as distinct from "0".

This would be more deterministic:

         A number is converted to an Erlang integer if its mathematical
         value is exactly representable as an integer, and it is not
         negative zero, and the option {float,true} was not passed.
         (A negative zero is "-" followed by any representation of zero.)
         Otherwise, it is converted to the nearest representable Erlang
         float using IEEE 754 round-to-even.

There's another round-trip issue besides the four listed in the Rationale:
JSON strings can include Unicode escapes that cause the string not
to be well-formed (for example, "\uDC00"). These will not round-trip,
because they will not convert to UTF-8. I don't think this is necessarily
much of a problem as long as it is documented.

-- 
David-Sarah Hopwood