[erlang-questions] fast JSON parser in C

Serge Aleynikov saleyn@REDACTED
Fri Jul 25 13:12:31 CEST 2008

Perhaps a little generalization would save us from having to add more 
BIFs like binary_to_* and *_to_binary in the future:

	proto_to_binary(Term, [{codec, Codec}]) -> binary()

	binary_to_proto(Bin::binary(), [{codec, Codec}]) -> Term

		Codec = json | Other

Also, this is not specific to the thread, but while on this subject, I 
don't quite understand why JavaScript Object Notation (JSON) is so 
heavily demanding double quoting everything in contrast to the 
JavaScript Object Notation built into all browsers.  What I mean is that 
the javascript interpreters built into browsers happily understand this 
notion of an object:

	{foo: 1, bar: "value"}
	{foo: 1, bar: 'value'}

whereas in JSON this would require to be written as:

	{"foo": 1, "bar": "value"}

The first form seems more natural for an Erlang programmer, and if JSON 
BIF parser is included in the OTP, perhaps a customization to support 
this variant of the format would be a worthwhile addition as most 
frequently JSON is used for interaction with browsers that happily 
accept the first, more compact, form.


Joe Armstrong wrote:
> Since JSON seem to be ubiquitous is seems to me that there would be
> a strong case for a couple of new BIFs,  term_to_json and json_to_term.
> these would work like binary_to_term and term_to_binary the difference
> being that
> instead of converting to a binary containing the external term format,
> we convert
> to a binary containing a JSON encoded string.
> I imaging that modeling this code on the existing term_to_binary and
> binary_to_term
> code would not be impossibly difficult (you have to make it reentrant
> and not to
> not hog the CPU for too long ... and so on ...)
> And yes - it is pretty horrid increasing the number of BIFs but this
> might just be
> a useful addition.
> This would ease seamless integration with a lot of external programs :-)
> /Joe Armstrong
> On Thu, Jul 24, 2008 at 11:02 AM, Martin Carlson
> <martin@REDACTED> wrote:
>> You might want to go with the ei interface rather than the erl_interface
>> since it is not as clumsy to use. Further, you might want to have a look
>> at the ejabberd expat driver and just replace the expat stuff with your
>> json SAX events.
>>  -Martin
>> Chris Anderson wrote:
>>> On Wed, Jul 23, 2008 at 1:49 PM, Jonathan Gray <jlist@REDACTED> wrote:
>>>> However when I get a big chunk (around 80-120K) directly from Erlang as
>>>> binary (using term_to_binary in erlang), I'm unable to decode it using
>>>> erl_interface erl_decode, though it can be decoded fine from within Erlang.
>>> Good to know - CouchDB's Erlang -> JSON encoding is fast enough to not
>>> need help from C. I'm just working on making the JSON -> Erlang fast
>>> enough, so as long as I can get string buffers over to C in the first
>>> place, it sounds like you're not having a problem moving data from C
>>> back to Erlang.
>>> Time to buckle down and code!
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions

More information about the erlang-questions mailing list