Richard,<div><br></div><div>Please excuse my ignorance, but can you name a single good reason for non-latin atoms and variable names? From my personal point of view, this is a sure road to hell.</div><div><br></div><div>How would you read these pieces of code:</div><div><br></div><div><div>Довж1 = length(Сп1)</div><div>[Г|Х]<br></div><div><br></div><div>?</div><div><br></div><div>Isn't it a blessing that we all are using a fairly short and commonly known alphabet and are able to communicate with each other, collaborate on open source projects, etc.?</div><div><br></div><div>Also, with regards to Unicode support, isn't the most important problem in handling external strings — i.e. data your system receives from outside?</div><div><br></div><div>Thanks,</div><div>Yurii.</div><br>On Thursday, October 18, 2012 11:07:05 PM UTC-7, Richard O'Keefe wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">If it were still possible to submit EEPs in plain text,<br>this would be an EEP.  If someone else would like to<br>package this up as an EEP and submit it (under their<br>name, mine, or both), feel free.<p>Forces:<br> (1) Support for Unicode continues to increase, with<br>     minimal source code support about to arrive.<br> (2) Unicode variable names and unquoted atoms are not<br>     here yet, so now is the time to settle on a design.<br> (3) They will need to come.  There may be legal or<br>     institutional reasons why unicode-capable languages<br>     are required.  Some people just want to use their<br>     own language and script.  Erlang's strength in<br>     network applications means that being able to<br>     represent Internationalized Domain Names as unquoted<br>     atoms would be just as much of a convenience as<br>     being able to represent ASCII domain names like<br>     <a href="http://www.example.com" target="_blank">www.example.com</a> (which needs no quotes in Erlang) is.<br> (4) There is a framework for Unicode identifiers in<br>     Unicode standard annex 31 (UAX#31), and several<br>     programming languages, including Ada, Java,<br>     C++, C, C#, Javascript, and Python (section 2.3 of<br>     <a href="http://docs.python.org/release/3.1.5/reference/lexical_analysis.html" target="_blank">http://docs.python.org/<wbr>release/3.1.5/reference/<wbr>lexical_analysis.html</a><br>     and see also <a href="http://www.python.org/dev/peps/pep-3131/" target="_blank">http://www.python.org/dev/<wbr>peps/pep-3131/</a><br> (5) Existing Erlang identifiers should remain valid,<br>     including ones containing "@" and ".".<br> (6) Existing Erlang support features, such as ignoring<br>     names of the form [_][a-zA-Z0-9_]* when reporting<br>     singleton variables, should not be broken.<br> (7) We should not "steal" any characters to use as "magic<br>     markers" for variables because they might be needed for<br>     other purposes.  A good (bad) example of this is "?", which<br>     could be used for several things if it were not used for macros.     </p><p>Reference</p><p>    Names of sets of characters, XID_Start, XID_Continue, Lu, Lt, Lo, Pc,<br>    Other_Id_Start, are drawn from Unicode and UAX#31.</p><p>        Lu = upper case letters<br>        Lt = title case letters<br>        Pc = connector punctuators, including the low line (_) and<br>             a number of other characters like undertie (‿).<br>        Other_Id_Start = script capital p, estimated symbol,<br>             katakana-hiragana voiced sound mark, and<br>             katakana-hiragana semi-voiced sound mark.</p><p>Variables</p><p>    variable ::= var_start var_continue*</p><p>    var_start ::= XID_Start ∩ (Lu ∪ Lt ∪ Pc ∪ Other_Id_Start)</p><p>    var_continue ::= XID_Continue U "@"</p><p>    The choice of XID here follows Python.  It ensures that the normalisation<br>    of a variable is still a variable.  In fact Unicode variables should be<br>    normalised.  Unicode has enough look-alike characters that we cannot hope<br>    for "look the same <=> are the same" to be true, but we should go _some_<br>    way in that direction.</p><p>    Variables in scripts that do not distinguish letter case have to<br>    begin with _some_ special character to ensure that they are not<br>    mistaken for unquoted atoms.  There are 10 Pc characters in the Basic<br>    Multilingual Plane.  The Erlang parser treats a variable beginning<br>    with an underscore specially: there will be no complaint if it is a<br>    singleton.  There are 9 other Pc characters for which this special<br>    treatment is not applied.  Of course, someone might be using fonts<br>    that do include say Arabic letters but not say the undertie.  We can<br>    deal with that by revising the underscore rule.</p><p>        Variable does not begin with a Pc character =><br>                should not be a singleton.</p><p>        Variable is just a Pc character and nothing else =><br>                is a wild card.</p><p>        Variable begins with a Pc character followed by a<br>        Latin-1 character =><br>                may be a singleton.</p><p>        Variable begins with a Pc character following by<br>        a character outside the Latin-1 range =><br>                should not be a singleton.</p><p>    Thus ‿ is a wild-card, 隠者 is an atom, _隠者 should not be<br>    a singleton, but __隠者 _may_ be a singleton.  This rule is a<br>    consistent generalisation of the existing rule.</p><p>Unquoted atoms</p><p>    unquoted_atom ::= atom_start atom_continue</p><p>    atom_start ::= XID_Start \ (Lu ∪ Lt ∪ Lo ∪ Pc)<br>                |  "." (Ll ∪ Lo)</p><p>    atom_continue ::= XID_Continue U "@"<br>                   |  "." (Ll ∪ Lo)</p><p>    Again the choice of XID follows Python, and ensures that the<br>    normalisation of an unquoted atom is still an unquoted atom.<br>    Unquoted atoms should be normalised.</p><p>    The details of Erlang unquoted atoms are somewhat subtle; I have<br>    checked my understanding experimentally.</p><p>Keywords</p><p>    Keywords have the form of unquoted atoms.  No new keywords are<br>    introduced.</p><p>Specifics</p><p>-  Any Python identifier or keyword is<br>   an Erlang variable or unquoted atom or keyword.</p><p>-  @ signs may occur freely in variables and unquoted atoms except as the<br>   first character, as now.</p><p>-  dots may not be followed by capital letters, digits, or underscores,<br>   as now.</p><p>-  I am not sure whether modifier letters should be allowed after a dot.</p><p>-  I am not sure what to do with the Other_ID_Start characters.<br>   Script capital p _looks_ like a capital p and even has "capital" in<br>   its name.  All other "* SCRIPT CAPITAL *" characters are upper case<br>   letters.  Surely it should be allowed to start a variable.<br>   The estimated sign looks like an enlarged lower case e; other symbols<br>   that look like letters are classified as letters.  You'd expect this<br>   to begin an atom.  As for the Katakana-Hiragana voicing marks, I have<br>   no intuition whatever.  Assigning the whole group to atoms seems<br>   safest.</p><p>-  All existing variable names and unquoted atoms remain legal, and no<br>   new variable or atom forms using only Latin-1 characters have been<br>   introduced.</p><p>Trouble spot<br>______________________________<wbr>_________________<br>erlang-questions mailing list<br><a href="javascript:" target="_blank" gdf-obfuscated-mailto="Wbt-2S9SjwoJ">erlang-q...@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p></blockquote></div>