[erlang-questions] json_to_term EEP
Richard A. O'Keefe
Mon Aug 4 04:23:52 CEST 2008
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
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
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.
is a legal JSON string.
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
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.
More information about the erlang-questions