[erlang-questions] EEP0018, some remarks

[Enrico Thierbach]

hi list,

whilst working on a native eep0018 implementation (
http://github.com/pboy/eep0018) I came across some problems with EEP0018.
The following is an excerpt from my README file, that states these issues:

============================================================================================

json_to_term/2 Options - Differences to EEP 18
==============================================

EEP0018 states

|       The {float,true} option says to convert all JSON numbers to
|       Erlang floats, even if they look like integers.
|       With this option, the result has type json(L, float()).
|
|       The {float,false} option says to convert integers to integers;
|       it is the default.
|       With this option, the result has type json(L, number()).
|
|       The {label,binary} option says to convert all JSON strings
|       to Erlang binaries, even if they are keys in key:value pairs.
|       With this option, the result has type json(binary(), N).
|       This is the default.
|
|       The {label,atom} option says to convert keys to atoms if
|       possible, leaving other strings as binaries.
|       With this option, the result has type json(json_label(), N).
|
|       The {label,existing_atom} option says to convert keys to
|       atoms if the atoms already exist, leaving other keys as
|       binaries.  All other strings remain binaries too.
|       With this option, the result has type json(json_label(), N).

Instead of that we implement the following options

{parse,object}(*) ...... Parse only Erlang objects and arrays, i.e. parsing
"123" would fail.
{parse,value}            Parse all Erlang values, i.e. parsing "123" would
succeed.

{objects,eep0018} ... (*) JSON objects will be mapped as laid out in
EEP0018, i.e.
                           {} -> [{}]
                           {"a":"b","c":"d"} ->
[{<<"a">>,<<"b">>},{<<"c">>,<<"d">>}]
{objects,compat}          JSON objects will be mapped as in some other
implementations, i.e.
                           {} -> {[]}
                           {"a":"b","c":"d"} ->
{[{<<"a">>,<<"b">>},{<<"c">>,<<"d">>}]}

{labels,binary} ... (*) Labels will be mapped as binaries, i.e.
                         {"a":"b","c":"d"} ->
{[{<<"a">>,<<"b">>},{<<"c">>,<<"d">>}]}
{labels,atom}           Labels will be mapped as binaries, i.e.
                         {"a":"b","c":"d"} -> {[{a,<<"b">>},{c,<<"d">>}]}
                       Use this option only if you know that there is a
limited range of
                       possible labels and that these labels can be
converted to atoms.

                       The {labels,existing_atom} option is not implemented,
because
                         a) it runs quite slow, and
                         b) the result of such an operation is
unpredictable.

{number,exact} ... (*) Numbers are parsed exactly as they are in the JSON
source code, i.e.
                      a JSON integer will be mapped as an Erlang integer,
and a JSON float
                      will be mapped as an Erlang float, in the precision
supported by the
                      current OTP runtime.
{number,number}        Numbers are parsed exactly as they are in the JSON
source code, i.e.
                      a JSON integer will be mapped as an Erlang integer,
and a JSON float
                      will be mapped as an Erlang float, in the precision
supported by the
                      C runtime and ei libraries, eg. signed 32-bit for
integers and 64 bit
                      floating points.
{number,float}         All numbers are parsed as an Erlang float, in the
precision supported
                      by the C runtime (eg. 64 bit).

Performance considerations
==========================

Some of these options have a huge performance impact, as they are
implemented on the Erlang side
and so require a two-step parsing process (one round in the driver and one
extra round in Erlang):

* {number,exact} is implemented by transmitting the number value as a string
* {objects,compat} is currently implemented in Erlang. A final
implementation -
  after everyone agreed upon the Erlang mapping of JSON objects, would of
  course be done in C.

============================================================================================

/eno

-- 
====================================================================
A wee piece of ruby every monday: http://1rad.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20090125/bc92d798/attachment.htm>