<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Regarding the use of Unicode in variables, here is a short list of
languages that allow it:<br>
<br>
- Ada<br>
- C#<br>
- Common Lisp<br>
- D<br>
- Delphi<br>
- GNU Forth (other impls are often ASCII only)<br>
- Go<br>
- Haskell<br>
- J<br>
- Java<br>
- Mathematica<br>
- Perl (also Perl 6)<br>
- Python<br>
- Racket<br>
- Tcl<br>
<br>
Now in any of these languages, can you blame the use of Unicode in
identifiers as the source of woes in there? Is it usually due to
semantics, other syntax, lack of clarity (even in English), their
community? Name me one language where unicode support is a true
problem compared to anything else, in this list.<br>
<br>
Is a Chinese programmer suddenly typing with her own glyphs rather
than pinyin a problem? If I'm programming in French already and had
my education in French, it's possible I learned everything using
French terminology:<br>
<br>
tableau -> array, arbre binaire -> binary tree, liste ->
list, paquet -> packet, octet -> byte, taille -> size,
fichier -> file, dossier -> directory, boucle -> loop<br>
<br>
and so on. Note that I can use all of these in my existing Erlang
programs if I want to, if I'm working with people who do not speak
English but still have a formal education in Computer Science,
software engineering, or whatever. Chances are that someone who
doesn't speak French won't have the best time reading that code, but
has it been a major problem so far? Would allowing, say accented
characters so someone can write 'colonne' and 'rangée' instead of
'colonne' and 'rangee' for 'column' and 'row', be the straw that
breaks the camel's back? Is the use of accents what's going to be
the problem here? Or are we supposed to be especially afraid of
non-latin-looking characters?<br>
<br>
I've mentioned to a few people here before that I'm coming from a
small part of Quebec where people don't speak English that well.
I've had to work on code bases where French was mandatory because
otherwise, people on your team wouldn't be able to understand what
the code was supposed to do. French code shoved in English exists,
and it's being used. I'm sure you know the same happens in a
boatload of other languages.<br>
<br>
Telling these people "well just Learn English, that's what I did
when I needed to" isn't a valid way of doing things. Nobody should
have to jump through the hoops we had to jump through, just because
we had to when we were learning. This isn't a reason enough. I'm not
willing to go back to my old office, and tell this father of 3
children (who programs to feed them) "Sorry buddy, you're out of a
job because apparently English is now necessary." It just won't
happen because it is *not* necessary to know English to program.<br>
<br>
As much as the huge github love circle and "code is global" thing
has been going, there's still an entire localized world out there
where people work in small private enterprises, providing local
services to people who speak their language, a place where people
don't give a shit whether user 'robocop56' stars your repository or
not. Programmers who want to go global can still write English stuff
all the same, lest they want to see their code shunned by the
majority of the world. That's likely what anyone using the listed
languages above did.<br>
<br>
This is no excuse to make it hard for everyone else to work in a way
they're comfortable. A huge part of programming is being able to
reason about code. Let programmers who want to do it, be able to do
so, especially when we see that so many languages support it
already, without most people even noticing.<br>
<br>
Here's one for you specifically Yurii: why would you want to keep
people from using a feature they want to use but that you wouldn't
use anyway?<br>
<br>
Regards,<br>
Fred.<br>
<br>
<br>
<div class="moz-cite-prefix">On 12-10-22 1:08 AM, Yurii Rashkovskii
wrote:<br>
</div>
<blockquote
cite="mid:2c7cbb95-f1c4-4aba-be7f-2f9630a89fb6@googlegroups.com"
type="cite">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 moz-do-not-send="true" 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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true" href="javascript:" target="_blank"
gdf-obfuscated-mailto="Wbt-2S9SjwoJ">erlang-q...@erlang.org</a><br>
<a moz-do-not-send="true"
href="http://erlang.org/mailman/listinfo/erlang-questions"
target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
</p>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
erlang-questions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
</blockquote>
<br>
</body>
</html>