[erlang-questions] strings, json, and what happens now

[Paul Phillips]

When I read something like this:

  http://www.lshift.net/blog/2007/09/13/how-should-json-strings-be-represented-in-erlang

It says to me that some decision has to be made about improving string
representations in erlang, or there are going to be several incompatible
implementations in the wild soon.

Are there good arguments against standardizing on an enhanced string
"type" of a tuple including the list of characters and whatever metadata
people are accustomed to having in other languages? I know this could be
done without core language support if you were willing to wrap and
unwrap it everytime you interacted with stdlib, or via a brand new
string library which operates on the tuples, which seems more likely. 
But there's already so much important code spread out among third party
libraries, it seems a shame to add to it, especially given the
immaturity of erlang's library mechanisms when compared to gem, cpan, etc.

I'm not particularly fascinated by character encodings and language
impedance mismatches, and I would suppose neither are most people, but
as someone presently trying to apply erlang in a real world setting this
issue is demanding a large percentage of my initial time investment.  Do
those who speak for the distribution see the string representation as a
problem? And is there some agreement on a way to deal with it?

Thanks,

-- 
Paul Phillips      | It's better to have gloved and tossed than never to
Analgesic          | have played baseball.
Empiricist         | 
all hip pupils!    |----------* http://www.improving.org/paulp/ *----------