[erlang-questions] json_to_term EEP

[Richard A. O'Keefe]

On 2 Aug 2008, at 2:21 am, David Mercer wrote:

> Does this signal that the Erlang community is moving away from
> strings-as-lists to strings-as-binaries?

Basically, I looked at what other people were doing with JSON->Erlang
conversion, and strings-as-binaries seemed to be the most popular  
choice.

Strings as binaries have some advantages.

(1) They are MUCH closer in spirit to what people expect strings to
     be.  I've lost count of the number of times people have said in
     this mailing list "Erlang is no XXXXXXX good because it doesn't
     have strings."  I'm sick of explaining why this is wrong.

(2) They _are_ more compact than lists, and if you want to pump data
     _through_ Erlang, reducing space turnover is a help.
     This is why I think strings-as-binaries with labels-as-atoms is
     a good balance; the part you expect to look inside using Erlang
     is easy to look at, the rest is cheap to hold and pass on.

(3) They offer constant-time slicing.

With the addition of <<"...">> syntax to Erlang they are almost
readable.

With Unicode, the major snag is that lists can represent one Unicode
character per element, whereas binary matching counts bytes.  Regular
expressions are coming, and if they can handle UTF-8 binaries we need
not worry too much about counting bytes.

>  Should we have an option in the
> JSON functionality to return keys and values as strings-as-lists?

This now leads us to the reason WHY other people are mapping JSON
strings to Erlang binaries.
	"ABC"
is a legal JSON string.
	[65,66,67]
is a legal JSON "array".  If we turned JSON strings into Erlang
strings, how would we tell them from "arrays"?  At least one of them
would have to be flagged somehow.

It might be pleasantly symmetric to have
	[array,65,66,67]
	[string,65,66,67]
	[object,......]
The thing is, you can't -just- say "let's have strings as lists",
you have to do something different with arrays/lists as well.

This really doesn't make a good default.