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

[Dmitry Belyaev]

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 <essen@REDACTED> 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> (SAP
>> internal)
>> Follow our latest activities in SAP CP User Community *Jam Group <
>> 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 <michael.nisi@REDACTED <mailto:
>>> michael.nisi@REDACTED>> 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, zxq9@REDACTED <mailto:zxq9@REDACTED> wrote:
>>>>
>>>> Erlang -> JSON
>>>> - true      -> true
>>>> - false     -> false
>>>> - undefined -> null
>>>> - Atom      -> String
>>>>
>>>> JSON -> Erlang
>>>> - true  -> true
>>>> - false -> false
>>>> - null  -> undefined
>>>>
>>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
> --
> Loïc Hoguin
> https://ninenines.eu
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180628/09487fba/attachment.htm>