[erlang-questions] json_to_term EEP

Paulo Sérgio Almeida psa@REDACTED
Mon Jul 28 23:51:23 CEST 2008


Chris Anderson wrote:

> the two options in Erlang are:
> Tuple of tuples (A):  {{<<"key">>, <<"value">>},{<<"key2">>, <<"value2">>}}
> or
> Tuple containing a list of tuples (B):  {[{<<"key">>,
> <<"value">>},{<<"key2">>, <<"value2">>}]}

I think there is no doubt that lists will be more useful than tuples. 
There is, however another option, that I have been using in a json 
parser I wrote:

(C) an object is simply a proplist, i.e. a list of tuples.

This is what one really wants to have in erlang. The difference to 
option (B) is that while if a single object is decoded it is easy to 
discard the outer {}, when objects are used inside other structures that 
is not the case anymore, and (C) will result in a greater chance of 
allowing a decoded structure to be stored as is with no post-processing 
in a useful erlang structure.

The only problem (C) poses is distinguishing the empty object from an 
empty array. My solution (which I am almost happy about) is to represent 
the empty object as [{}]. This way:

- objects can be distinguished from arrays, e.g. by the following function:

is_object(O=[T|_]) when is_tuple(T) -> true;
is_object(_) -> false.

- we can use objects as proplists, use functions like lists:keysearch or 
list comprehensions like

Keys = [V || {V,_} <- Object]

which will work even for the special empty object [{}].

Anyway, the empty object is not a common case (at least for my 
purposes), and the advantages of being able to store nested objects in 
the most pleasant way is something that should make one consider option (C).

As others have said, I also do not consider option (A) useful.


P.S. Given the sudden interest in json, I will describe the options I 
took in my parser and make it available in a subsequent post, to further 

More information about the erlang-questions mailing list