[erlang-questions] fast JSON parser in C

Bob Ippolito bob@REDACTED
Sat Jul 26 17:15:51 CEST 2008

On Fri, Jul 25, 2008 at 6:48 PM, Serge Aleynikov <saleyn@REDACTED> wrote:
> Bob Ippolito wrote:
>> On Fri, Jul 25, 2008 at 4:12 AM, Serge Aleynikov <saleyn@REDACTED> wrote:
>>> 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"}
>>>               or
>>>       {foo: 1, bar: 'value'}
>>> whereas in JSON this would require to be written as:
>>>       {"foo": 1, "bar": "value"}
>> ... because it is a lot simpler and easier to write correct
>> implementations if you remove extraneous features. Ease of
>> interoperability is more important than aesthetic or compactness. If
>> you want something convenient for humans you should implement YAML,
>> but good luck writing a correct parser for that in a reasonable amount
>> of time ;)
> While generally your statement above is impeccable when it comes to "fancy"
> features, given the simplicity of this requirement, I don't see how removing
> double quotes from object properties would *significantly* complicate the
> parser.  In fact, I have done this customization of the publicly available
> json.erl implementation and if I recall it only involved changes to a couple
> of lines of code to support this feature.

You overestimate the abilities of many JSON library implementors :)

> Not sure about others but I do find this "variant of JSON" more convenient
> when it comes to debugging JavaScript in a browser (using Firebug debugger)
> as it is visually more compact and not taking as much of screen real estate.

With firebug you can just look at the objects themselves once they're evaluated.

>>> 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.
>> That's just a bad idea. If you intend to do that, don't call it JSON
>> because it's not.
>> Not every JSON client is a JavaScript interpreter
>> using eval().
> Perhaps using JSON name for the JSON protocol was a misnomer in the first
> place, as it has very little to do with JavaScript other than resembling its
> object notation?

It's not any worse than the name JavaScript to begin with.


More information about the erlang-questions mailing list