<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 6 Jun 2018, at 14:00, Vlad Dumitrescu <<a href="mailto:vladdu55@gmail.com" class="">vladdu55@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi!<div class=""><br class=""></div><div class="">I have a few thoughts about this. I would favor the proposed syntax, but not if things don't get simpler. What I mean is that there's more to consider.</div></div></div></blockquote><div><br class=""></div><div>I was aware of having missed a few details, and aware I was undoubtedly unaware of more :)</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">- Some modules don't handle binary strings, but lists of chars; most notably erl_scan. If the syntaxes are too close, it might be even more confusing when to use which form.</div></div></div></blockquote><div><br class=""></div><div>Very true, though equally some modules don’t handle lists of chars. erl_scan is a big one, but I guess we are all used to the endless round of list to binary and vice versa in these cases.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">- The new string functions work with strings as sequences of lexemes. The "list strings" are lists of characters, so for example calling length() on the two representations of the same text may not return the same value. Most notably, CRLF is a lexeme, but two characters.</div></div></div></blockquote><div><br class=""></div><div>That is a big question. How should they be represented? I was happily assuming UTF-8, but maybe it would make more sense for them to be compatible with the new string module and be stored as lexeme sequences.</div><div><br class=""></div><div>Looking around it seems there are a good range of sensible options. Elixir defaults to string literals being utf8, Swift uses Unicode scalars in their internal string representation forcing conversion to get a byte based representation.</div><div><br class=""></div><div>With my protocol hat on I think I would pick utf8 as that is the most likely external representation and in many cases we would never need to convert and hence be efficient, but I can see arguments for this being poor design for a language.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">- When working with a textual protocol, it's still quite often that one would use <<"prefix"/utf8, Rest/binary>>, where the current syntax still has to be used. It might be confusing?</div></div></div></blockquote><div><br class=""></div><div><<#”prefix”, Rest/binary>> ?</div><div><br class=""></div><div>Definitely room for deeper thought here.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">- The predefined type string() is still <span style="color:rgb(26,26,26);font-family:mono,Courier,monospace;font-size:11.2px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(243,243,243);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline" class="">[char()], </span>and for binary strings there is unicode:chardata(), which in not necessarily obvious (as these are handled by the string module).</div></div></div></blockquote><div><br class=""></div><div>There is a type for unicode_binary() in the unicode module which refers to a utf8 binary string. The unicode.erl docs go as far as saying:</div><div><br class=""></div><div>"The default Unicode encoding in Erlang is in binaries UTF-8, which is also the format in which built-in functions and libraries in OTP expect to find binary Unicode data”</div><div><br class=""></div><div>There is also a strange example in the string.erl document where this binary <<"abc..åäö”>> is not stored as UTF-8 but instead as latin-1. Having an unambiguous way to represent a UTF-8 string literal would also clear this up.</div><div><br class=""></div><div>That seems to point in a clear direction.</div><div><br class=""></div><div>Excellent input, thank you.</div><div><br class=""></div><div>Sean</div></div><br class=""></body></html>