[erlang-questions] New project: ZJ - A tiny JSON encoder/decoder

Oleg Tarasenko <>
Thu Jun 28 09:46:10 CEST 2018


Hi Craig,

The lib looks interesting, I would like to try it on my projects.

Few related questions:
1) Do you plan to add tests later on?
2) What do you think about publishing it on hex.pm, so it's easier
to control releases (for those who are using it), maybe rebar3/erlang.mk
can be quite helpful here?
3) Finally, the performance, did you have a chance to make some comparisons?

Best regards,
Oleg


On Thu, Jun 28, 2018 at 9:31 AM Loïc Hoguin <> wrote:

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


More information about the erlang-questions mailing list