[erlang-questions] No JSON/MAPS interoperability in 17.0?

[Jesper Louis Andersen]

Hi,

Some important points to consider:

* If you put a library into stdlib, it becomes a slow moving target. That
is, changes to this library will take months. Since maps are so new, it
would be better to iterate the library outside the standard release in any
case. Cutting down the OTP standard libraries is an important goal since it
unties the hands of the OTP team so they have to maintain less code.

* I think the parsing/unparsing is the least of the problems to handle. We
can, with proper options, work around oddities that doesn't follow the
standard correctly in both directions.

* The library API however, is going to be hard to tackle. Some will want a
C-NIF because lolspeed. Some will want stability and an implementation in
Erlang. Some will want SAX-style parsing and some just wants a term fully
decoded. Some will want an enumerator/iteratee pattern for chunked decoding
over a socket. Some will hate streaming. Some will like to inject
transforming functions into the JSON parser. Some will want the ability to
turn JSON objects into erlang records. And so on. Any implementation will
only support a subset of this.

The different implementations have differing guarantees. I think this is
good because we avoid one-library-to-rule-them-all and the bad design
symptoms it brings.


On Mon, Mar 10, 2014 at 3:43 AM, liuyanghejerry <liuyanghejerry@REDACTED>wrote:

>
>  The fact that you always have to think about where the JSON will be
>> injected?
>>
>
> Yes I do, because I really hope Erlang std lib has it so I can use it
> without searching "what JSON package do you use with Erlang", without
> considering too much about compatibility, etc. Yes, I want my life easier
> with Erlang.
>
>
>  What about a JSON-encoded string containing "</script>", should that be
>> avoided by Erlang’s builtin parser? What about "]]>"? What about the two
>> characters that are accepted in JSON but not in JavaScript?
>>
>
> JSON is not really that tight with JavaScript and HTML, you may want to
> learn more[1].
>
>
>
>> Just because other languages include such a thing doesn’t mean Erlang
>> should too. If diversity is not a reason to reject it, other languages
>> providing it is not a reason to include it either.
>>
>>
> Yes, it is my point that it's not a reason to reject it. Since you're
> questioning how parsers should behave, there're lots of "examples" in other
> languages.
>
> [1]: http://www.ecma-international.org/publications/files/ECMA-
> ST/ECMA-404.pdf
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>



-- 
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140310/703a6ba1/attachment.htm>