<div dir="ltr">Hi,<div><br></div><div>Some important points to consider:</div><div><br></div><div>* 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.</div>

<div><br></div><div>* 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.</div><div><br>

</div><div>* 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.</div>

<div><br></div><div>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.</div></div><div class="gmail_extra"><br>

<br><div class="gmail_quote">On Mon, Mar 10, 2014 at 3:43 AM, liuyanghejerry <span dir="ltr"><<a href="mailto:liuyanghejerry@126.com" target="_blank">liuyanghejerry@126.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The fact that you always have to think about where the JSON will be injected?<br>
</blockquote>
<br></div>
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.<div class="">

<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br>


</blockquote>
<br></div>
JSON is not really that tight with JavaScript and HTML, you may want to learn more[1].<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
</blockquote>
<br></div>
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.<br>
<br>
[1]: <a href="http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf" target="_blank">http://www.ecma-international.<u></u>org/publications/files/ECMA-<u></u>ST/ECMA-404.pdf</a><div class="HOEnZb"><div class="h5">

<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>J.
</div>