There are many pros and cons for switching from Latin-1 to UTF-8 (or whatever else which will nullify pretty much the understanding of byte character). On one hand, lists:reverse/1 really messes up the characters in the list (to follow the first example, the output of "a∞b" in Latin-1 is totally different from the output of lists:reverse("b∞a") in Latin-1 - the default now). On the other hand, having, for example, Polish characters like "Ą Ę Ć" or French "Ç Î" or German "Ö ß" or Turkish "Ş" and so on (things become more complicated if we add languages based on different alphabet/symbols) in the code would require your editor to have support for those languages or else you will see really strange characters there. I do not deny some specific projects would benefit from such a character encoding, but think of maintaining such a code in an international environment.<div>
<br></div><div>"-encoding()" can make quite a mess in a file. Think of an open source project in which devs from different countries append their own code. You will see a lot of "-encoding()" directives in a single file.</div>
<div><br></div><div>I might be wrong, but, switching to default UTF-8, wouldn't that force the compiler to use 2-byte (at least) per character? If so, for example, what about the databases based on Erlang for projects using strict Latin-1?</div>
<div><br></div><div>My point here is that the string manipulation should be kept apart from the code itself and to have two modules for manipulating normal lists and IO-lists (e.g., by extending unicode module). But that would be my own preference.</div>
<div><br></div><div>CGS</div><div><br></div><div><br><br><div class="gmail_quote">On Tue, Jul 31, 2012 at 10:10 AM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 07/31/2012 09:53 AM, Masklinn wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2012-07-31, at 09:39 , Michel Rijnders wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Jul 31, 2012 at 9:05 AM, Joe Armstrong <<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is "encoding(...)"  a good idea?<br>
<br>
There are four reasonable alternatives<br>
<br>
    a) - all files are Latin1<br>
    b) - all files are UTF8<br>
    c) - all files are Latin1 or UTF8 and you guess<br>
    d) - all files are Latin1 or UTF8 or anything else and you tell<br>
</blockquote>
<br>
I understand it is quite drastic but I would prefer a separate data<br>
type for (unicode) strings.<br>
</blockquote>
<br>
For historical reasons? Because on technical grounds, the existing<br>
scheme would work nicely by declaring that the integers are code points.<br>
And because Unicode is identical to latin-1 in the first 256 codepoints,<br>
latin1 strings would be identical.<br>
<br>
The `string` module would probably need to be fixed to be unicode-aware<br>
(or deprecated and removed altogether in favor of the unicode one), but<br>
I'm not sure there are good reasons to change the datatype.[-1]<br>
<br>
On the other hand, a dedicated datatype could allow things like Python's<br>
new Flexible String Representation[0] where an explicit "list of code<br>
points" would not allow such flexibility.<br>
<br>
The only thing I'd rather avoid is moving from "list of latin-1 bytes" to<br>
"list of utf-8 bytes", that's just crap.<br>
</blockquote>
<br></div>
If strings are kept as lists:<br>
<br>
- there is no way to identify a variable as being a list or latin1 string or utf8 string<br>
- you would have to keep track of what encoding your list is in<br>
- you would have to do some type conversion when you use them with functions like gen_tcp:send, which don't accept lists of integers > 255<br>
<br>
If strings are a new type:<br>
<br>
- you don't care about the encoding most of the time, Erlang is the one who should; if you want to know the encoding you could use a new BIF encoding(String)<br>
- you don't need to do type conversion when using it, Erlang can use the string type directly<br>
- you can convert encoding without caring about what the previous encoding was, for example str:convert(Str, utf8); if it was utf8 it doesn't change a thing, if it wasn't it's converted<br>
- you can export it as a list or binary in the encoding you want, for example str:to_binary(Str, utf8)<br>
- you still need to specify the encoding when converting a list or binary to string, but maybe we could have niceties like << Str/string-utf8 >>?<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Loïc Hoguin<br>
Erlang Cowboy<br>
Nine Nines<br>
<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a></font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>