New project: ZJ - A tiny JSON encoder/decoder

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

New project: ZJ - A tiny JSON encoder/decoder

zxq9-2
With tuple calls gone and mochijson2 finally going extinct I found myself in need of a strings-as-strings JSON encoder/decoder in pure Erlang (not NIF-based). I wrote one yesterday. It is a single module that exports two functions: encode/1 and decode/1. Erlang didn't really *need* another JSON encoder/decoder, of course, but this one works exactly the way I need -- if anyone else finds it useful you're welcome to it:

https://gitlab.com/zxq9/zj

A few tradeoffs have to be made when writing a JSON encoder/decoder because JSON types don't map very well with Erlang, and everyone has different optimal performance profiles and data idioms within their programs. The mappings ZJ follows are below. Note that tuples map to JSON arrays, which means proplists do NOT map to JSON objects, Erlang maps do.

JSON -> Erlang:
 * Integer -> Integer
 * Float   -> Float
 * String  -> String
 * Object  -> Map
 * Array   -> List
 * true    -> true
 * false   -> false
 * null    -> null

Erlang -> JSON:
 * Integer -> Integer
 * Float   -> Float
 * Map     -> Object
 * List    -> Array
 * Tuple   -> Array
 * Binary  -> String
 * UTF-8   -> String
 * true    -> true
 * false   -> false
 * null    -> null


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: New project: ZJ - A tiny JSON encoder/decoder

Dmitry Kolesnikov-2
Hello,

It looks promising, thank you for sharing!

However, I’d like to suggest to consider mapping `null -> null`.
I’ve been raising a similar issue to jsx as well.

The atom `undefined` is used by many library to express undefined result.
Please consider its usage

JSON -> Erlang:
* null -> undefined

Erlang -> JSON
* undefined -> null

Best Regards,
Dmitry


> On 26 Jun 2018, at 12.58, [hidden email] wrote:
>
> With tuple calls gone and mochijson2 finally going extinct I found myself in need of a strings-as-strings JSON encoder/decoder in pure Erlang (not NIF-based). I wrote one yesterday. It is a single module that exports two functions: encode/1 and decode/1. Erlang didn't really *need* another JSON encoder/decoder, of course, but this one works exactly the way I need -- if anyone else finds it useful you're welcome to it:
>
> https://gitlab.com/zxq9/zj
>
> A few tradeoffs have to be made when writing a JSON encoder/decoder because JSON types don't map very well with Erlang, and everyone has different optimal performance profiles and data idioms within their programs. The mappings ZJ follows are below. Note that tuples map to JSON arrays, which means proplists do NOT map to JSON objects, Erlang maps do.
>
> JSON -> Erlang:
> * Integer -> Integer
> * Float   -> Float
> * String  -> String
> * Object  -> Map
> * Array   -> List
> * true    -> true
> * false   -> false
> * null    -> null
>
> Erlang -> JSON:
> * Integer -> Integer
> * Float   -> Float
> * Map     -> Object
> * List    -> Array
> * Tuple   -> Array
> * Binary  -> String
> * UTF-8   -> String
> * true    -> true
> * false   -> false
> * null    -> null
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New project: ZJ - A tiny JSON encoder/decoder

zxq9-2
In reply to this post by zxq9-2
On 2018年6月26日火曜日 18時58分55秒 JST [hidden email] wrote:
> With tuple calls gone and mochijson2 finally going extinct I found
> myself in need of a strings-as-strings JSON encoder/decoder in pure
> Erlang (not NIF-based). I wrote one yesterday. It is a single module
> that exports two functions: encode/1 and decode/1. Erlang didn't really
> *need* another JSON encoder/decoder, of course, but this one works
> exactly the way I need -- if anyone else finds it useful you're welcome
> to it:
>
> https://gitlab.com/zxq9/zj


Quick update...

Two new functions have been added, binary_encode/1 and binary_decode/1.
The purpose of these new functions is to disambiguate between strings
and arrays. Most of the time this is not necessary (it seems the vast
majority of JSON data floating around is snippets of ASCII), but it is
easy to provide for so I added these this morning.

Since someone is already using this I'm calling it v1.0.0, as I intend
to support this 4-function interface for a while.

https://gitlab.com/zxq9/zj#binary_decode1

Just one more option in the ocean of JSON encode/decode libs!

-Craig
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: New project: ZJ - A tiny JSON encoder/decoder

zxq9-2
In reply to this post by Dmitry Kolesnikov-2
On 2018年6月26日火曜日 16時44分08秒 JST you wrote:

> Hello,
>
> It looks promising, thank you for sharing!
>
> However, I’d like to suggest to consider mapping `null -> null`.
> I’ve been raising a similar issue to jsx as well.
>
> The atom `undefined` is used by many library to express undefined result.
> Please consider its usage
>
> JSON -> Erlang:
> * null -> undefined
>
> Erlang -> JSON
> * undefined -> null

Hmmm... That changes semantics a bit.

I understand what you're saying, but that would mean:

Erlang -> JSON
- null      -> null
- undefined -> null

Is that really desirable? Seems a bit "fuzzy"/surprising.
I'm not faced with this anywhere, so I really don't know.

Thoughts from anyone else?

-Craig
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: New project: ZJ - A tiny JSON encoder/decoder

Max Lapshin-2
I also think that  erlang undefined should be converted to  json  null and back.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: New project: ZJ - A tiny JSON encoder/decoder

Roger Lipscombe-2
If we were dealing with records, I'd argue that 'undefined' should map
to *omitted*, but we're dealing with maps, so... (shrugs).

Incidentally:
- https://github.com/davisp/jiffy/issues/4
- https://github.com/davisp/jiffy/issues/27
- https://github.com/talentdeficit/jsx/issues/18

On 27 June 2018 at 07:06, Max Lapshin <[hidden email]> wrote:
> I also think that  erlang undefined should be converted to  json  null and
> back.
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: New project: ZJ - A tiny JSON encoder/decoder

zxq9-2
On 2018年6月27日水曜日 8時05分59秒 JST Roger Lipscombe wrote:

> If we were dealing with records, I'd argue that 'undefined' should map
> to *omitted*, but we're dealing with maps, so... (shrugs).
>
> Incidentally:
> - https://github.com/davisp/jiffy/issues/4
> - https://github.com/davisp/jiffy/issues/27
> - https://github.com/talentdeficit/jsx/issues/18
>
> On 27 June 2018 at 07:06, Max Lapshin <[hidden email]> wrote:
> > I also think that  erlang undefined should be converted to  json  null and
> > back.


Indeed. On reflection the argument for translating the semantic VS merely
passing along the label that conveys it has won me over.

I pulled the v1.0.0 tag that I had *just* pushed and reworked it.

ZJ's type mapping: https://gitlab.com/zxq9/zj#type-mapping

Erlang -> JSON
- true      -> true
- false     -> false
- undefined -> null
- Atom      -> String

JSON -> Erlang
- true  -> true
- false -> false
- null  -> undefined

Note that non-special atoms map to strings, and that includes 'null' now
mapping to "null".

Thanks, fellas.

-Craig
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: New project: ZJ - A tiny JSON encoder/decoder

Michael Nisi
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, [hidden email] wrote:
>
> Erlang -> JSON
> - true      -> true
> - false     -> false
> - undefined -> null
> - Atom      -> String
>
> JSON -> Erlang
> - true  -> true
> - false -> false
> - null  -> undefined
>

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: New project: ZJ - A tiny JSON encoder/decoder

Marc Worrell
I agree with mapping ‘null' to ‘undefined' and vice versa.

An issue with ‘null’ in JavaScript versus Erlang is that in JavaScript ‘null’ does have meaning.
In Erlang it is just another random atom.

Consider in JavaScript:

> if (null) console.log('yeah');
< undefined
> if (!null) console.log('yeah');
[Log] yeah

In Erlang libraries only ‘undefined’ is handled.
If you need to interface the received JSON to Erlang then you need to either
change the libraries or add mapping code.

To me it seems to be pragmatic to let the decoder use ‘undefined’ instead of ‘null’.

- Marc
 

> On 27 Jun 2018, at 09:42, Michael Nisi <[hidden email]> 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, [hidden email] wrote:
>>
>> Erlang -> JSON
>> - true      -> true
>> - false     -> false
>> - undefined -> null
>> - Atom      -> String
>>
>> JSON -> Erlang
>> - true  -> true
>> - false -> false
>> - null  -> undefined
>>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: New project: ZJ - A tiny JSON encoder/decoder

zxq9-2
In reply to this post by zxq9-2
On 2018年6月27日水曜日 13時29分34秒 JST [hidden email] wrote:

> On 2018年6月26日火曜日 18時58分55秒 JST [hidden email] wrote:
> > With tuple calls gone and mochijson2 finally going extinct I found
> > myself in need of a strings-as-strings JSON encoder/decoder in pure
> > Erlang (not NIF-based). I wrote one yesterday. It is a single module
> > that exports two functions: encode/1 and decode/1. Erlang didn't really
> > *need* another JSON encoder/decoder, of course, but this one works
> > exactly the way I need -- if anyone else finds it useful you're welcome
> > to it:
> >
> > https://gitlab.com/zxq9/zj
>
>
> Quick update...
>
> Two new functions have been added, binary_encode/1 and binary_decode/1.
> The purpose of these new functions is to disambiguate between strings
> and arrays. Most of the time this is not necessary (it seems the vast
> majority of JSON data floating around is snippets of ASCII), but it is
> easy to provide for so I added these this morning.
>
> Since someone is already using this I'm calling it v1.0.0, as I intend
> to support this 4-function interface for a while.
>
> https://gitlab.com/zxq9/zj#binary_decode1
>
> Just one more option in the ocean of JSON encode/decode libs!

And one final status update...

Marc Worrell kindly reminded me that I still had GPL-3.0 as the license.

That's changed. ZJ is now under the MIT license.

-Craig
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: New project: ZJ - A tiny JSON encoder/decoder

Whealy, Chris
In reply to this post by Michael Nisi
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 (SAP internal)
Follow our latest activities in SAP CP User Community Jam Group 

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 <[hidden email]> 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, [hidden email] wrote:

Erlang -> JSON
- true      -> true
- false     -> false
- undefined -> null
- Atom      -> String

JSON -> Erlang
- true  -> true
- false -> false
- null  -> undefined


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: New project: ZJ - A tiny JSON encoder/decoder

zxq9-2
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.
https://tools.ietf.org/html/rfc8259

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.

-Craig
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: New project: ZJ - A tiny JSON encoder/decoder

Loïc Hoguin-3
In reply to this post by Whealy, Chris
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 <[hidden email]
>> <mailto:[hidden email]>> 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, [hidden email] <mailto:[hidden email]> wrote:
>>>
>>> Erlang -> JSON
>>> - true      -> true
>>> - false     -> false
>>> - undefined -> null
>>> - Atom      -> String
>>>
>>> JSON -> Erlang
>>> - true  -> true
>>> - false -> false
>>> - null  -> undefined
>>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email] <mailto:[hidden email]>
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: New project: ZJ - A tiny JSON encoder/decoder

Dmitry Belyaev-3
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 <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> 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, [hidden email] <mailto:[hidden email]> wrote:

Erlang -> JSON
- true      -> true
- false     -> false
- undefined -> null
- Atom      -> String

JSON -> Erlang
- true  -> true
- false -> false
- null  -> undefined


_______________________________________________
erlang-questions mailing list
[hidden email] <mailto:[hidden email]>
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


--
Loïc Hoguin
https://ninenines.eu

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: New project: ZJ - A tiny JSON encoder/decoder

zxq9-2
On 2018年6月28日木曜日 14時49分49秒 JST Dmitry Belyaev wrote:
> 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.

We've discussed that more than a few times. The problem is that there is
no "right" mapping because JSON, lacking almost all useful types, is
extremely lossy.

JSX handles objects as proplists in encoding and decoding, but can
decode them as maps if you tell it to.

ZJ handles maps objects to Erlang maps directly, and tuples to lists,
meaning you a proplist encoded to JSON becomes a list of ordered pairs.

Which one is right?

They both are, technically speaking, but one or the other is going to
suit a given project better than the other -- and as a library author
there is no way to know which way will suit project X better ahead of
time.

zj:encode/1 and zj:decode/1 are list-based -- which leaves some ambiguity
but works better in *most* cases. zj:binary_encode/1 and zj:binary_decode/1
is strict about strings being binaries and lists being lists, closer to
the way JSX works.

Which one is right?

That's not possible to know.

Fortunately we live in a world where using JSX or ZJ or Jiffy (if your
platform can build C, anyway) or writing your own isn't hard, so we
get more options this way. I think that's a LOT better situation than
burdening the core distribution team with trying to pick the "right"
way, that falling through and instead having to maintain a zillion
optional arguments for encode and decode, maintaining a portable C
codebase, and dealing with all the complaints that will inevitably
result from there ever having been a default chosen in advance (whatever
defaults are innocently chosen for encode/1 and decode/1 will surely
be wrong in the view of over half the users out there).

I really like that Erlang is a "batteries included" language, but thre
are clear limits. Consider how many projects can't use httpc, the
built-in web parsers, or similar tools. How much other work could be
done were the maintenance burden of those bits removed? Not to mention
backward compatibile maintenance being a tarbaby all its own...

-Craig
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: New project: ZJ - A tiny JSON encoder/decoder

Loïc Hoguin-3
In reply to this post by Dmitry Belyaev-3
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 <[hidden email]
> <mailto:[hidden email]>> 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
>             <[hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email]
>             <mailto:[hidden email]>>> 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, [hidden email]
>                 <mailto:[hidden email]> <mailto:[hidden email]
>                 <mailto:[hidden email]>> wrote:
>
>                 Erlang -> JSON
>                 - true      -> true
>                 - false     -> false
>                 - undefined -> null
>                 - Atom      -> String
>
>                 JSON -> Erlang
>                 - true  -> true
>                 - false -> false
>                 - null  -> undefined
>
>
>             _______________________________________________
>             erlang-questions mailing list
>             [hidden email]
>             <mailto:[hidden email]>
>             <mailto:[hidden email]
>             <mailto:[hidden email]>>
>             http://erlang.org/mailman/listinfo/erlang-questions
>             <http://erlang.org/mailman/listinfo/erlang-questions>
>
>
>
>
>         _______________________________________________
>         erlang-questions mailing list
>         [hidden email] <mailto:[hidden email]>
>         http://erlang.org/mailman/listinfo/erlang-questions
>         <http://erlang.org/mailman/listinfo/erlang-questions>
>
>
>     --
>     Loïc Hoguin
>     https://ninenines.eu
>
>     _______________________________________________
>     erlang-questions mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://erlang.org/mailman/listinfo/erlang-questions
>     <http://erlang.org/mailman/listinfo/erlang-questions>
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: New project: ZJ - A tiny JSON encoder/decoder

Oleg Tarasenko
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 <[hidden email]> 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 <[hidden email]
> <mailto:[hidden email]>> 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
>             <[hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email]
>             <mailto:[hidden email]>>> 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, [hidden email]
>                 <mailto:[hidden email]> <mailto:[hidden email]
>                 <mailto:[hidden email]>> wrote:
>
>                 Erlang -> JSON
>                 - true      -> true
>                 - false     -> false
>                 - undefined -> null
>                 - Atom      -> String
>
>                 JSON -> Erlang
>                 - true  -> true
>                 - false -> false
>                 - null  -> undefined
>
>
>             _______________________________________________
>             erlang-questions mailing list
>             [hidden email]
>             <mailto:[hidden email]>
>             <mailto:[hidden email]
>             <mailto:[hidden email]>>
>             http://erlang.org/mailman/listinfo/erlang-questions
>             <http://erlang.org/mailman/listinfo/erlang-questions>
>
>
>
>
>         _______________________________________________
>         erlang-questions mailing list
>         [hidden email] <mailto:[hidden email]>
>         http://erlang.org/mailman/listinfo/erlang-questions
>         <http://erlang.org/mailman/listinfo/erlang-questions>
>
>
>     --
>     Loïc Hoguin
>     https://ninenines.eu
>
>     _______________________________________________
>     erlang-questions mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://erlang.org/mailman/listinfo/erlang-questions
>     <http://erlang.org/mailman/listinfo/erlang-questions>
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: New project: ZJ - A tiny JSON encoder/decoder

zxq9-2
On 2018年6月28日木曜日 9時46分10秒 JST you wrote:

> 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?

Hi, Oleg!

1- I fuzzed it by running real-world JSON through it, but am not convinced
of the utility of hand-written tests considering how narrow the actual
spec is compared to the variety of real-world illegal JSON out there. I
think the best way to *really* approach testing would be to write a script
that would evaluate its performance against either a bulk dataset stored
for that purpose or (much better) use PropEr.

I'm open to that, but don't have the time right now. It works for my cases
exactly as I intended, but I'm certainly open to contributions.

I fully realize my position is heretical.


2- If someone wants to push it to hex.pm that would be swell! I don't use
hex.pm in any projects at the moment, so it is a very low priority. Again,
more of a time issue for me than anything. My "extra" time budget wound up
getting spent on making sure the docs came out properly.

Same as #1, I'm open to that and would love to see it packaged for others
to use in a more simple way -- but it isn't a personal priority for me at
the moment. It will, however, be part of Zomp's default FOSS repository
once I get around to releasing that (so will JSX).


3- The only function I benchmarked formally was decode/1. It performed
about 5% (+/- 10) faster than JSX decode/1 -- so for all practical
purposes is the same. The *size* of the output of decode/1 is larger than
JSX when dealing with strings because decode/1 returns strings-as-strings,
not binaries. This is better for some kinds of manipulation, but isn't
very compact.

binary_decode/1 almost certainly performs a little slower than decode/1
because I didn't implement that in a particularly efficient way. I can
improve it to a comparable speed if that becomes necessary, though.
Anyway, this has not been benchmarked formally, just poked at with
timer:tc/1 a few times (but that isn't a particularly reliable way to
benchmark things).

I have not benchmarked encode/1 or binary_encode/1 at all, but would be
very surprised if they are meaningfully slower than JSX as the approach
taken is very similar -- the mapping between JSON <=> Erlang types being
the important difference.


Nice to hear from you!

-Craig
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: New project: ZJ - A tiny JSON encoder/decoder

Michał Muskała
For testing JSON parsers/encoders I recommend https://github.com/nst/JSONTestSuite

Michał.
On 28 Jun 2018, 10:17 +0200, [hidden email], wrote:
On 2018年6月28日木曜日 9時46分10秒 JST you wrote:
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?

Hi, Oleg!

1- I fuzzed it by running real-world JSON through it, but am not convinced
of the utility of hand-written tests considering how narrow the actual
spec is compared to the variety of real-world illegal JSON out there. I
think the best way to *really* approach testing would be to write a script
that would evaluate its performance against either a bulk dataset stored
for that purpose or (much better) use PropEr.

I'm open to that, but don't have the time right now. It works for my cases
exactly as I intended, but I'm certainly open to contributions.

I fully realize my position is heretical.


2- If someone wants to push it to hex.pm that would be swell! I don't use
hex.pm in any projects at the moment, so it is a very low priority. Again,
more of a time issue for me than anything. My "extra" time budget wound up
getting spent on making sure the docs came out properly.

Same as #1, I'm open to that and would love to see it packaged for others
to use in a more simple way -- but it isn't a personal priority for me at
the moment. It will, however, be part of Zomp's default FOSS repository
once I get around to releasing that (so will JSX).


3- The only function I benchmarked formally was decode/1. It performed
about 5% (+/- 10) faster than JSX decode/1 -- so for all practical
purposes is the same. The *size* of the output of decode/1 is larger than
JSX when dealing with strings because decode/1 returns strings-as-strings,
not binaries. This is better for some kinds of manipulation, but isn't
very compact.

binary_decode/1 almost certainly performs a little slower than decode/1
because I didn't implement that in a particularly efficient way. I can
improve it to a comparable speed if that becomes necessary, though.
Anyway, this has not been benchmarked formally, just poked at with
timer:tc/1 a few times (but that isn't a particularly reliable way to
benchmark things).

I have not benchmarked encode/1 or binary_encode/1 at all, but would be
very surprised if they are meaningfully slower than JSX as the approach
taken is very similar -- the mapping between JSON <=> Erlang types being
the important difference.


Nice to hear from you!

-Craig
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: New project: ZJ - A tiny JSON encoder/decoder

zxq9-2
On 2018年6月28日木曜日 10時44分13秒 JST you wrote:
> For testing JSON parsers/encoders I recommend https://github.com/nst/JSONTestSuite

Thanks, Michał!

Over the weekend I might hook the two together.
If it isn't too complicated I might drop a script for this in there.

Very cool.

-Craig
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
12