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

Wed Jun 27 10:53:00 CEST 2018

On 2018年6月27日水曜日 8時43分39秒 JST you 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.

If I were mapping JavaScript I would agree -- but I am not, I am mapping JSON as defined by RFC-8259, which is distinct from JavaScript/ECMAScript.

RFC-8259 does not define the atom 'undefined' at all, whereas Erlang does.

Most existing JSON encoders/decoders either don't map "undefined" (since it shouldn't occur in JSON at all) or map "undefined" -> 'undefined' as you suggest above. ZJ provides a (clearly desired) alternative to this.

Fortunately there are enough JSON encoders/decoders around that finding the flavor that fits a given project best is mostly a matter of shopping around and testing.

That said, there is a little wiggle room for real-world flexibility. ZJ accepts a couple of dirty malformations in JSON already (trailing commas, partial parse errors) and adding a function that performs an explicit mapping for an illegal literal isn't really such a stretch.


More information about the erlang-questions mailing list