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>