So just for my own understanding, and as it seems extremely important ( strings are quite important these days!), as it stands now:<div><br></div><div>iolists cant can only ( officially?) contain utf8? ( as no utf8 code point will exceed  255, like latin1 / asci, and are therefor are all byte() )</div>
<div><br></div><div>strings can be of utf8 utf16 or utf32, but only the utf8 version is allowed in an iolist? ( and therefore if you wanted an "iolist" ( eg a non flat list of chars) that contained utf 16 or 32 code points you would have to stick exclusively to lists ( strings) and not binaries and use lists:flatten before you finished with it, to remove all the nested lists )<br>
<br></div><div>binaries can be of any unicode type..</div><div><br></div><div>also there does seem to be a needed distinction between char() and byte() as they are not the same at all, but the documentation is wrong as at the moment iolists can infact only contain byte() not char()</div>
<div><br></div><div>the suggested direction is to repair the docs so that they specify only allowing 0~255 ints( byte() ) in iolists rather than allowing io-lists to contain any string as they did before the introduction of unicode / in the days of latin1 etc.. ?</div>
<div><br></div><div><br></div><div>i think that that goes agents most ( even erlang implementers :-) ) opinion of what an iolist is ( that being a list of any valid string or binary) but maybe ( to raise a totally different problem) would prevent the possibility of an iolist having a mixed unicode type and still begin "valid" ( even tho i guess this is still possible as binaries can in fact be other utf representations)</div>
<div><br></div><div><br></div><div><br><div class="gmail_quote">On 2 May 2011 11:13, Kostis Sagonas <span dir="ltr"><<a href="mailto:kostis@cs.ntua.gr">kostis@cs.ntua.gr</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">Raimo Niskanen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This became messy when char() was re-defined from latin-1 character<br>
to unicode character. That affected string() that affected iolist()<br>
and the latter was incorrect.<br>
<br>
We must clean up the mess.<br>
</blockquote>
<br></div>
Right.  The sooner it happens the better it is.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
... Either by completing the notion of char()<div class="im"><br>
being unicode and hence rewriting iolist() to contain byte() and binary(),<br>
or by reverting to char() being latin-1 char and using unicode:char()<br>
and unicode:string() where that is correct...<br>
</div></blockquote>
<br>
Please, by all means do the former.  The latter will only cause havoc everywhere.  For starters, I do not see any need in having two different basic types (byte() and char()) denoting (pretty much) the same thing. The only thing this does is cause unnecessary confusion to newcomers (and apparently to some old-timers too).  Second, if you choose the latter you will eventually have to change lots of type inference code, because I promise you I will not do this, and believe me you don't want to go there... (The Vietnam jungle is probably a friendlier place ;) )<br>

<br>
Cheers,<br><font color="#888888">
Kostis</font><div><div></div><div class="h5"><br>
_______________________________________________<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/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>