<div dir="ltr">Hi Craig,<div><br></div><div>The lib looks interesting, I would like to try it on my projects. </div><div><br></div><div>Few related questions:</div><div>1) Do you plan to add tests later on? </div><div>2) What do you think about publishing it on <a href="http://hex.pm">hex.pm</a>, so it's easier to control releases (for those who are using it), maybe rebar3/<a href="http://erlang.mk">erlang.mk</a> can be quite helpful here?</div><div>3) Finally, the performance, did you have a chance to make some comparisons?</div><div><br></div><div>Best regards,</div><div>Oleg</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 28, 2018 at 9:31 AM Loïc Hoguin <<a href="mailto:essen@ninenines.eu">essen@ninenines.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Again I'm questioning why you insist on comparing it to Javascript. JSON <br>
is used with pretty much all languages and there is no 1:1 language-JSON <br>
mapping that I know of, including Javascript. JSON is a <br>
language-agnostic serialization format.<br>
<br>
JSON does not have the Javascript undefined. The only way to get the <br>
Javascript undefined out of JSON is by not defining a JSON object's <br>
field at all. In Erlang we do this by not defining the map field at all.<br>
<br>
JSON has null, it corresponds to the Javascript null and is pretty much <br>
what we use undefined for in Erlang. In maps it represents a field that <br>
has a key defined but no value.<br>
<br>
This library uses maps for objects. Not records, not proplists, so <br>
there's no pernicious issue with implicit undefined (records' default <br>
undefined or proplists:get_value's default undefined). All undefined <br>
values are set explicitly by the user to mean the same as null. I do not <br>
see an issue with that.<br>
<br>
Cheers,<br>
<br>
On 06/28/2018 06:49 AM, Dmitry Belyaev wrote:<br>
> I could never understand where this conversion JSON null <-> Erlang <br>
> undefined was coming from.<br>
> <br>
> Of course we generally don't use null atom in the code, but I always <br>
> considered "undefined" value in Erlang meaning "absent" value. For <br>
> example when a record is created and some field is not populated <br>
> explicitly, it is set undefined.<br>
> This logic is very similar to Javascript objects with missing fields. <br>
> Consider Javascript parsing a JSON object and fetching fields from it. <br>
> If a key was not present in the JSON, undefined would be returned, which <br>
> is different from null.<br>
> <br>
> That example always made me think, that undefined values on Erlang side <br>
> should be seen on Javascript side as undefined values too. And to make <br>
> sure this works that way, the attributes holding atom undefined had to <br>
> be not present in the resulting JSON.<br>
> <br>
> There is another example from Javascript world:<br>
> > JSON.stringify({a: 1, b: undefined, c: null})<br>
> < "{"a":1,"c":null}"<br>
> <br>
> So I'd say that to keep semantics synchronised, the conversions should <br>
> be JSON null <-> Erlang null, and Erlang undefined values in objects <br>
> must be simply removed from the resulting JSON object.<br>
> <br>
> Anyway, what I'd actually greet as a serious improvement in handling of <br>
> JSON in our small Erlang world would be an introduction of "SAX JSON" <br>
> parser (similar to what jsx does) as part of the standard Erlang <br>
> distribution and implemented in C. That way we would have parsing <br>
> separated from construction of the representation, and anyone would be <br>
> able to use whatever representation they like.<br>
> <br>
> Kind regards,<br>
> Dmitry Belyaev<br>
> <br>
> On Wed, Jun 27, 2018 at 6:56 PM, Loïc Hoguin <<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a> <br>
> <mailto:<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>>> wrote:<br>
> <br>
> You are conflating Javascript and JSON. JSON was originally defined<br>
> as a subset of Javascript, but it has very little to do with it<br>
> otherwise.<br>
> <br>
> There is no 'undefined' JSON type. There is only 'null'. The<br>
> Javascript 'undefined' is irrelevant because it doesn't translate<br>
> into JSON to begin with.<br>
> <br>
> That being said, both the Javascript 'undefined' and 'null'<br>
> translate to the JSON 'null'. They are not treated as distinct. The<br>
> JSON 'null' has roughly the same semantics as the Erlang 'undefined'<br>
> so the mapping makes sense and makes using JSON libraries easier as<br>
> long as the JSON library uses maps and not proplists.<br>
> <br>
> Cheers,<br>
> <br>
> On 06/27/2018 10:43 AM, Whealy, Chris wrote:<br>
> <br>
> Allow me to elaborate on your point Michael (also without<br>
> getting philosophical).<br>
> <br>
> In JavaScript null and undefined are identifiably distinct<br>
> datatypes that serve specific purposes:<br>
> <br>
> * *null* - This variable specifically has no value<br>
> * *undefined* - The value of this variable is indeterminate (I.E.<br>
> identifiably different from null)<br>
> <br>
> <br>
> Although the atom null has no special meaning in Erlang, it does<br>
> when mapped to JavaScript null; therefore to maintain accuracy,<br>
> Erlang devs who also work in JavaScript should understand and<br>
> preserve this semantic difference. Likewise with Erlang<br>
> undefined mapping to JavaScript undefined.<br>
> <br>
> Therefore, I submit that this semantic difference should be<br>
> persevered when mapping from Erlang to JavaScript, otherwise<br>
> data loss will occur, particularly when mapping from JavaScript<br>
> back to Erlang.<br>
> <br>
> Erlang -> JavaScript<br>
> null -> null<br>
> undefined -> undefined<br>
> <br>
> JavaScript -> Erlang<br>
> null -> null<br>
> undefined -> undefined<br>
> <br>
> This part of the mapping table at least should be bijective.<br>
> <br>
> *Chris Whealy*<br>
> <br>
> SAP Cloud Platform | Strategy & Product Management | Team<br>
> <br>
> *SAP UK Ltd,* Clockhouse Place, Bedfont Rd, Feltham, Middx, TW14<br>
> 8HA, England<br>
> <br>
> M +44 (0)7808 575377<br>
> <br>
> Find out more on the Strategy & Product Management***Wiki page*<br>
> <<a href="https://wiki.wdf.sap.corp/wiki/pages/viewpage.action?pageId=1865737441" rel="noreferrer" target="_blank">https://wiki.wdf.sap.corp/wiki/pages/viewpage.action?pageId=1865737441</a><br>
> <<a href="https://wiki.wdf.sap.corp/wiki/pages/viewpage.action?pageId=1865737441" rel="noreferrer" target="_blank">https://wiki.wdf.sap.corp/wiki/pages/viewpage.action?pageId=1865737441</a>>> (SAP<br>
> internal)<br>
> Follow our latest activities in SAP CP User Community *Jam Group<br>
> <<a href="https://jam4.sapjam.com/groups/about_page/eopqUq5S182gY7JFrbdwis" rel="noreferrer" target="_blank">https://jam4.sapjam.com/groups/about_page/eopqUq5S182gY7JFrbdwis</a> <<a href="https://jam4.sapjam.com/groups/about_page/eopqUq5S182gY7JFrbdwis" rel="noreferrer" target="_blank">https://jam4.sapjam.com/groups/about_page/eopqUq5S182gY7JFrbdwis</a>>>*<br>
> <br>
> Please consider the impact on the environment before printing<br>
> this e-mail.<br>
> <br>
> Twitter: @LogaRhythm<br>
> /"The voice of ignorance speaks loud and long,/<br>
> / but the words of the wise are quiet and few"/<br>
> / Ancient Proverb/<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> On 27 Jun 2018, at 08:42, Michael Nisi<br>
> <<a href="mailto:michael.nisi@gmail.com" target="_blank">michael.nisi@gmail.com</a> <mailto:<a href="mailto:michael.nisi@gmail.com" target="_blank">michael.nisi@gmail.com</a>><br>
> <mailto:<a href="mailto:michael.nisi@gmail.com" target="_blank">michael.nisi@gmail.com</a><br>
> <mailto:<a href="mailto:michael.nisi@gmail.com" target="_blank">michael.nisi@gmail.com</a>>>> wrote:<br>
> <br>
> Here’s how v8::JSON, the JSON parser in Node’s JavaScript<br>
> engine, does it:<br>
> <br>
> JSON.stringify({})<br>
> <br>
> '{}'<br>
> <br>
> JSON.stringify({ name: null })<br>
> <br>
> '{"name":null}'<br>
> <br>
> JSON.stringify({ name: undefined })<br>
> <br>
> '{}'<br>
> <br>
> JSON.stringify({ name: 'Lionel' })<br>
> <br>
> '{"name":"Lionel"}’<br>
> <br>
> JSON.parse('{}').name<br>
> <br>
> undefined<br>
> <br>
> JSON.parse('{ "name": null }').name<br>
> <br>
> null<br>
> <br>
> JavaScript differentiates between null and undefined,<br>
> without wanting to get philosophical here.<br>
> <br>
> Michael<br>
> <br>
> <br>
> On 27. Jun 2018, at 09:21, <a href="mailto:zxq9@zxq9.com" target="_blank">zxq9@zxq9.com</a><br>
> <mailto:<a href="mailto:zxq9@zxq9.com" target="_blank">zxq9@zxq9.com</a>> <mailto:<a href="mailto:zxq9@zxq9.com" target="_blank">zxq9@zxq9.com</a><br>
> <mailto:<a href="mailto:zxq9@zxq9.com" target="_blank">zxq9@zxq9.com</a>>> wrote:<br>
> <br>
> Erlang -> JSON<br>
> - true -> true<br>
> - false -> false<br>
> - undefined -> null<br>
> - Atom -> String<br>
> <br>
> JSON -> Erlang<br>
> - true -> true<br>
> - false -> false<br>
> - null -> undefined<br>
> <br>
> <br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
> <mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>><br>
> <mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
> <mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>>><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
> <<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a>><br>
> <br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a> <mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
> <<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a>><br>
> <br>
> <br>
> -- <br>
> Loïc Hoguin<br>
> <a href="https://ninenines.eu" rel="noreferrer" target="_blank">https://ninenines.eu</a><br>
> <br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a> <mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
> <<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a>><br>
> <br>
> <br>
> <br>
> <br>
> _______________________________________________<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" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
> <br>
<br>
-- <br>
Loïc Hoguin<br>
<a href="https://ninenines.eu" rel="noreferrer" target="_blank">https://ninenines.eu</a><br>
_______________________________________________<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" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>