I think it very much depends on what you are going to do with the string. If you are going to store for later then using a binary with some encoding (UTF-8, UTF-16, ...) is probably the best. But if you are are going to *work* with it then keeping it as a list of codepoints is much better, much better in fact than keeping them in arrays like C++ type strings.
<br><br>How to handle the metadata I don't know. If I remember correctly from a previous discussion the metadata was not really standardised and could be a bit messy.<br><br>Robert<br><br><div><span class="gmail_quote">
On 24/09/2007, <b class="gmail_sendername">Paul Phillips</b> <<a href="mailto:paulp@improving.org">paulp@improving.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
When I read something like this:<br><br>  <a href="http://www.lshift.net/blog/2007/09/13/how-should-json-strings-be-represented-in-erlang">http://www.lshift.net/blog/2007/09/13/how-should-json-strings-be-represented-in-erlang
</a><br><br>It says to me that some decision has to be made about improving string<br>representations in erlang, or there are going to be several incompatible<br>implementations in the wild soon.<br><br>Are there good arguments against standardizing on an enhanced string
<br>"type" of a tuple including the list of characters and whatever metadata<br>people are accustomed to having in other languages? I know this could be<br>done without core language support if you were willing to wrap and
<br>unwrap it everytime you interacted with stdlib, or via a brand new<br>string library which operates on the tuples, which seems more likely.<br>But there's already so much important code spread out among third party
<br>libraries, it seems a shame to add to it, especially given the<br>immaturity of erlang's library mechanisms when compared to gem, cpan, etc.<br><br>I'm not particularly fascinated by character encodings and language
<br>impedance mismatches, and I would suppose neither are most people, but<br>as someone presently trying to apply erlang in a real world setting this<br>issue is demanding a large percentage of my initial time investment.  Do
<br>those who speak for the distribution see the string representation as a<br>problem? And is there some agreement on a way to deal with it?<br><br>Thanks,<br><br>--<br>Paul Phillips      | It's better to have gloved and tossed than never to
<br>Analgesic          | have played baseball.<br>Empiricist         |<br>all hip pupils!    |----------* <a href="http://www.improving.org/paulp/">http://www.improving.org/paulp/</a> *----------<br>_______________________________________________
<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br><a href="http://www.erlang.org/mailman/listinfo/erlang-questions">http://www.erlang.org/mailman/listinfo/erlang-questions
</a><br></blockquote></div><br>