[erlang-questions] JSON for STDLIB

[zxq9]

On 2015年9月7日 月曜日 21:57:35 Theepan wrote:
> Other then floats, I don't see issues in handling the others.
> 
> Key order is not defined in JSON, and JavaScript engines are handling it in
> different ways. When you have the keys, order might not be important. If
> the order is important, define a parameter for each key that is sortable.
> 
> If the keys are not unique, the first key will be selected - for example OR
> define one key and put the values into an array.
> 
> Some expectations need to be set.

That is the problem. Javascript/ECMA standards are a big fat mess. Erlang standards are, for the most part, not. We have ways of handling JSON, but each method differs somewhat. There is no clear optimum for JSON against which a goal could be set, no definite "this is the right way to do JSON that is technically sound, reasonably easy to use, and efficient". 

Defining such a goal would be the first step -- because once Erlang includes something like that as a core library we are *all* stuck with it (and supporting that particular API) forever and ever and ever, amen. Goal definition in the face of sloppy standards is already a non-trivial task. In the presence of decent (but very different) third party libs that already exist it is hard to see what the cost in terms of effort would actually buy us, especially considering that...

There is not a great clamor for this. If there is, it certainly hasn't hit the mailing list yet.

The problem is a lot deeper than "floats" (and anyway, js/JSON lacks integers; everything is already a float -- which is another ball of poo we don't need to deal with inside a core library). It also happens to lack atoms. And ordered dicts. And... anyway, there really isn't a clear mapping.

In the face of this ambiguity it is a good thing that we have several third party libs that cater to different interpretations/mapping *and* exhibit different performance characteristics instead of a central canonical library that has to make enough compromises to get included that it just doesn't quite suit anyone's actual use case, and is therefore left lonely in the core libs, unused by most (the way various XML libs in several language core libs have been, for example) but still a derelict maintenance burden.

I think the argument for including bzip2 and lzma2 is much stronger, if for no other reason than it is an unambiguous goal with a very clear and obvious implementation path. But even that is a tough sell.

-Craig