<p>+1 to ROK's ideas from me.</p>
<p>We should be allowing programmers and programming teams to make their own decisions regarding which characters to allow within projects. If people want to play tricks on each other by replacing ASCII chars with visibly indistinguishable chars from somewhere else, then that's their own business. We have the technology to be culturally sensitive and responsive. If someone is willing to invest energy to implement Unicode, we as a community should not put barriers in front of that.</p>
<div class="gmail_quote">On Nov 1, 2012 6:27 PM, "Richard O'Keefe" <<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 1/11/2012, at 3:44 AM, Raimo Niskanen wrote:<br>
><br>
> Was it not ment to be:<br>
> var_start ::= (XID_Start ∩ (Lu ∪ Lt ∪ Other_ID_Start)) ∪ Pc<br>
<br>
Yes. I made a mistake there.<br>
><br>
> More restricted variable names<br>
> ------------------------------<br>
><br>
> Nevertheless, I would like a slightly more conservative change in how Erlang<br>
> should use Unicode in variable names and unquoted atoms.<br>
><br>
> I want to be able to read printed source code on a paper and at least<br>
> understand if Ƽ = count() has a variable, an atom or an integer to the left.<br>
> This is an impossible goal because we can today e.g Cyrillic А in any .erl<br>
> file and that will look as it should compile but it will not.<br>
<br>
I am a little puzzled here. U+0410 (CYRILLIC CAPITAL LETTER A) looks<br>
like this: А. I grant you that it is somewhere between exceptionally<br>
difficult and impossible to tell an A from an А from an Α (Latin<br>
capital A, Cyrillic, and Greek respectively). But they are all capital<br>
letters. The point of the proposal is that since А (U+0410) is a<br>
capital letter, А = count() _should_ compile.<br>
<br>
If the example had been U+1EFD ỽ (LATIN SMALL LETTER MIDDLE-WELSH V)<br>
that would have been hard to tell from a six, true.<br>
But I don't see how this is any different from the fact that in a script<br>
you don't know, you cannot tell _what_ a character is.<br>
For example, I had a student this year whose native language was I<br>
believe Malayalam. I can't tell a Malayalam letter from a digit from<br>
a punctuation mark.<br>
<br>
Did you mean U+0417 (CYRILLIC CAPITAL LETTER ZE) "З", which resembles 3?<br>
<br>
Ah! Emacs to the rescue. It's the LATIN CAPITAL LETTER TONE FIVE.<br>
Nothing to do with Cyrillic.<br>
<br>
Reverting to the Middle Welsh letter, if I cannot tell a small letter<br>
from a digit, does that mean that every unquoted atom should begin<br>
with an English letter? (I cannot say "a Latin letter", because<br>
ỽ _is_ a member of the extended Latin script.)<br>
<br>
No, I'm sorry. This is ridiculous. Expecting everybody to begin<br>
_their_ variables which you will almost certainly never see to begin<br>
with an ASCII letter so _you_ can tell this from that; what sense does<br>
that make? If it is in a script you cannot read, then you cannot read it.<br>
<br>
Can we just try, for a minute or to, to entertain a rather wild idea?<br>
Here's the idea: most programmers are adults. They can make informed<br>
choices. If they *want* you to read their code, they are smart enough<br>
to write in a script you can read. If they decide that it's more<br>
important to them that _they_ can read comfortably, that's their<br>
decision to make. If you want a Malayalam-speaker to write code for<br>
you, put the language (English, Finnish, whatever) in the contract.<br>
<br>
I have a confession to make. My multiple-programming-languages to<br>
multiple-styled-output-formats tool is currently Latin-1 only.<br>
That's because it's for _me_; nobody paid me to write it and I didn't<br>
expect anyone else to find it useful (although someone did). It can,<br>
for example, be configured to generate HTML, and it can be made to<br>
wrap keywords in <B> and could as easily wrap variables in <U>. It<br>
would probably take me about a week to revised the thing to use<br>
Unicode. So then I'd have a tool that could generate printed listings<br>
with variables underlined, without needing to slap untold numbers of<br>
people in the face with the notion that they are and must remain<br>
second-class world citizens.<br>
<br>
> So I have to change that requirement into; if it compiles I want to be able<br>
> to tell from a noncolour printed source code listing what the semantics is.<br>
<br>
You are, in fact, proposing a backwards-incompatible change to Erlang,<br>
in order to achieve a goal which is not in general achievable, and not<br>
in my view worth achieving if you could.<br>
<br>
Let's be realistic here. If you cannot read any of the words, it is not<br>
going to do you any good to tell the variables from the atoms from the<br>
numbers. Let's take an example. I took a snippet of Erlang out of<br>
the Erlang/OTP release and transliterated the English letters to<br>
Russian ones. If you _don't_ read the Cyrillic script, precisely what<br>
good does it do you to know which are the variables? If you _do_ read<br>
the Cyrillic script, this will seem to you to be complete gibberish,<br>
so imagine it's a language you don't know.<br>
<br>
ҵӄҽҲӃҸҾҽ({ҵӄҽҲӃҸҾҽ,ҝҰҼҴ,ҐӁҸӃӈ,Ґӂ0,ҥұ,ҥҳұ}, ҐӃҾҼҜҾҳ, ҢӃ0) -><br>
try<br>
{ҐӂҼ,ҔҽӃӁӈқҰұҴһ,ҢӃ} = ҲҶ_ҵӄҽ(ҥұ, Ґӂ0, ҥҳұ, ҐӃҾҼҜҾҳ, {ҝҰҼҴ,ҐӁҸӃӈ}, ҢӃ0),<br>
ҕӄҽҲ = {ҵӄҽҲӃҸҾҽ,ҝҰҼҴ,ҐӁҸӃӈ,ҔҽӃӁӈқҰұҴһ,ҐӂҼ},<br>
{ҕӄҽҲ,ҢӃ}<br>
catch<br>
ҒһҰӂӂ:ҔӁӁҾӁ -><br>
ҢӃҰҲҺ = ҴӁһҰҽҶ:ҶҴӃ_ӂӃҰҲҺӃӁҰҲҴ(),<br>
ҸҾ:ҵӆӁҸӃҴ("ҕӄҽҲӃҸҾҽ: ~ӆ/~ӆ\ҽ", [ҝҰҼҴ,ҐӁҸӃӈ]),<br>
ҴӁһҰҽҶ:ӁҰҸӂҴ(ҒһҰӂӂ, ҔӁӁҾӁ, ҢӃҰҲҺ)<br>
end.<br>
<br>
ҲҶ_ҵӄҽ(қҴӂ, җӅӂ, ҥҳұ, ҐӃҾҼҜҾҳ, ҝҰҼҴҐӁҸӃӈ, ҢӃ0) -><br>
{ҕҸ,ҢӃ1} = ҽҴӆ_һҰұҴһ(ҢӃ0),<br>
{ҕһ,ҢӃ2} = һҾҲҰһ_ҵӄҽҲ_һҰұҴһ(ҝҰҼҴҐӁҸӃӈ, ҢӃ1),<br>
<br>
ґҴҵ = ҲһҴҰӁ_ҳҴҰҳ(#ӂӁ{ӁҴҶ=ҵҾһҳһ(fun ({ӅҰӁ,ҥ}, ҡҴҶ) -><br>
ҿӄӃ_ӁҴҶ(ҥ, ҡҴҶ)<br>
end, [], җӅӂ),<br>
ӂӃҺ=[]}, 0, ҥҳұ),<br>
{ґ2,_ҐҵӃ,ҢӃ3} = ҲҶ_һҸӂӃ(қҴӂ, 0, ҥҳұ, ґҴҵ,<br>
ҢӃ2#ҲҶ{ұӃӈҿҴ=ҴӇҸӃ,ұҵҰҸһ=ҕҸ,ҵҸҽҵҾ=ҕҸ,Ҹӂ_ӃҾҿ_ұһҾҲҺ=ӃӁӄҴ}),<br>
{ҝҰҼҴ,ҐӁҸӃӈ} = ҝҰҼҴҐӁҸӃӈ,<br>
Ґ = [{һҰұҴһ,ҕҸ},{ҵӄҽҲ_ҸҽҵҾ,ҐӃҾҼҜҾҳ,{ҰӃҾҼ,ҝҰҼҴ},ҐӁҸӃӈ},<br>
{һҰұҴһ,ҕһ}|ґ2],<br>
{Ґ,ҕһ,ҢӃ3}.<br>
<br>
I don't know about you, but I wouldn't dare to touch this.<br>
It DOES NOT MATTER TO me which words are variables and which<br>
are not, because that knowledge is not useful to me.<br>
<br>
(By the way, it should now be clear that in a context like this<br>
you'll _know_ that something is a Cyrillic capital A because<br>
everything else is Cyrillic -- there are no capital letters in<br>
keywords -- so what would a Latin capital A be doing there?)<br>
<br>
Does that mean there will be Erlang files that I cannot read and<br>
Raimo Niskanen cannot read? Certainly it does. Does that mean a<br>
big problem for us? No. Nobody is going to _expect_ us to read<br>
it. If someone ships us source code we can't read we shan't use<br>
it.<br>
<br>
Is this a NEW problem? No. It is already possible to use some<br>
surprising languages in ASCII (Klingon, Ancient Egyptian, Greek<br>
with a little ingenuity, ...) so ever since Erlang began, we've<br>
had the possibility of entire files being written in words that<br>
we did not understand. If you don't know what the *functions*<br>
are about, what good does it do you to know which tokens are<br>
variables?<br>
<br>
I once had to maintain a large chunk of Prolog written by a<br>
very clever programmer whose idea of good variable naming<br>
style came from old BASIC (one letter, or one letter and one<br>
digit). I could see _which_ tokens were the variables, but<br>
not _what_ the variable names meant. I had to figure it out<br>
from the predicate names. So from actual experience I can<br>
tell you<br>
<br>
JUST KNOWING WHICH TOKENS ARE VARIABLES IS<br>
NEXT TO USELESS.<br>
<br>
> I think it is better to restrict to a subset of 7-bit US-ASCII.<br>
<br>
Yeah! Let's make Erlang ASCII-only! (Too bad about my father's<br>
middle name: Æneas. Perfectly good English name, from Latin.)<br>
<br>
> Decent<br>
> editors have means (vim: ga, emacs: Ctrl-X describe-char) to show which<br>
> character is under the cursor and if it is A..Z or _ under U+7F it is a<br>
> variable start.<br>
<br>
I'm using Aquamacs.<br>
>From the Aquamacs help:<br>
Emacs buffers and strings support a large repertoire of<br>
characters from many different scripts, allowing users to<br>
type and display text in almost any known written language.<br>
<br>
To support this multitude of characters and scripts,<br>
Emacs closely follows the Unicode Standard.<br>
It's Meta-X describe-char, not Ctrl-X describe-char,<br>
and it works perfectly with Unicode characters.<br>
Here's sample output:<br>
<br>
character: Ҳ (1202, #o2262, #x4b2)<br>
preferred charset: unicode (Unicode (ISO10646))<br>
code point: 0x04B2<br>
syntax: w which means: word<br>
category: .:Base, y:Cyrillic<br>
buffer code: #xD2 #xB2<br>
file code: #xD2 #xB2 (encoded by coding system utf-8)<br>
display: by this font (glyph code)<br>
nil:-apple-Lucida_Grande-medium-normal-normal-*-13-*-*-*-p-0-iso10646-1 (#x8A3)<br>
<br>
Character code properties: customize what to show<br>
name: CYRILLIC CAPITAL LETTER HA WITH DESCENDER<br>
old-name: CYRILLIC CAPITAL LETTER KHA WITH RIGHT DESCENDER<br>
general-category: Lu (Letter, Uppercase)<br>
<br>
Trying this in Vim, it tells me what the numeric codes<br>
of a letter are, but not that it is a letter.<br>
<br>
><br>
> The underscore<br>
> --------------<br>
><br>
> I would like to argue against allowing all Unicode general category Pc<br>
> (Connector_Punctuation) character in place of "_". This class contain<br>
> in Unicode 6.2 these characters:<br>
> U+5F; LOW LINE<br>
> U+2034; UNDERTIE<br>
> U+2040; CHARACTER TIE<br>
> U+2054; INVERTED UNDERTIE<br>
> U+FE33; PRESENTATION FORM FOR VERTICAL LOW LINE<br>
> U+FE33; PRESENTATION FORM FOR VERTICAL WAVY LOW LINE<br>
> U+FE4D; DASHED LOW LINE<br>
> U+FE4E; CENTERLINE LOW LINE<br>
> U+FE4F; WAVY LOW LINE<br>
> U+FF3F; FULLWIDTH LOW LINE<br>
><br>
> Of these at least U+2040 "⁀" is horizontal at the top of the line<br>
<br>
If it looks horizontal, you have a very poor font.<br>
It's _supposed_ to look more like a c rotated 90 degrees<br>
clockwise and flattened a bit.<br>
<br>
> and U+FE33 "︳" looks like a vertical bar (I guess intended for<br>
> vertical flow chinese) so they do not resemble "_" very much.<br>
<br>
Who said they were _supposed_ to resemble "_"?<br>
Not me.<br>
<br>
I can see your point here, but allowing-all-of-Pc *is* the<br>
Unicode UAX#31 recommendation. We *have* to tailor the<br>
definition somewhat for the sake of backwards compatibility<br>
(dots and at signs). We *could* tailor it here, but it is<br>
definitely advantageous to have at least one more Pc<br>
character reasons given in the EEP.<br>
<br>
> Allowing all these would make it hard to remember if a given<br>
> character is category Pc or something else e.g "|".<br>
<br>
You are not *supposed* to remember what each and every character is.<br>
<br>
BECAUSE YOU CAN'T.<br>
<br>
If there's anyone who can, I don't want to meet them.<br>
What _else_ could we talk about?<br>
<br>
There are 110,117 defined characters in Unicode 6.2.<br>
(The figure was 110,116 in Unicode 6.1 and 6.2 added one more.)<br>
NOBODY is expected to know what all these characters are.<br>
<br>
The idea is not<br>
"if a character is to appear in an Erlang file,<br>
everybody must know what it means"<br>
but<br>
"if someone wants to use their own script in<br>
an Erlang file, they should be able to do so<br>
in a way that is generally consistent with<br>
other programming languages."<br>
<br>
The idea that a character should be forbidden unless YOU<br>
recognise it would take us right back to ASCII or Latin 1.<br>
Please, do not put the cart before the horse.<br>
<br>
It is perfectly acceptable to say "If someone wants to share<br>
Erlang code with people in other countries, they should use<br>
characters that all those people recognise." In the 21st<br>
century it is no longer acceptable to say "nobody may use a<br>
character unless I remember what it is."<br>
><br>
> Unquoted atoms<br>
> --------------<br>
><br>
> The EEP proposes:<br>
> atom_start ::= XID_Start ∖ (Lu ∪ Lt ∪ Lo ∪ Pc)<br>
> | "." (Ll ∪ Lo)<br>
><br>
> I agree that Lu (Uppercase_Letter) and Lt (Titlecase_Letter) should<br>
> be excluded so an atom can not start with a capital looking letter,<br>
> but Pc ⊄ XID_Start so there is no reason to subtract it, and why<br>
> subtract Lo (Other_Letter)?<br>
<br>
There is also no *harm* in making it obvious that variables<br>
*can* start with Pc characters and unquoted atoms *cannot*.<br>
<br>
Why subtract Lo? That was a combination of a backwards compatibility<br>
issue and an oversight.<br>
<br>
The backwards compatibility issue is that<br>
ªº are Lo characters and are not allowed to begin an Erlang atom.<br>
The oversight was forgetting that this category was the one with<br>
most of the characters I wanted to allow.<br>
<br>
This should read<br>
<br>
atom_start ::= XID_Start \ (Lu ∪ Lt ∪ "ªº")<br>
| "." (Ll ∪ Lo)<br>
<br>
> There also seems to be a typo in the definition of unquoted_atom<br>
> where an iteration of atom_continue is missing.<br>
><br>
> I propose:<br>
> unquoted_atom ::= atom_start atom_continue*<br>
<br>
Yes.<br>
><br>
> atom_start ::= atom_start_char<br>
> | "." atom_start_char<br>
<br>
That will allow Latin-1 atoms that are not now legal.<br>
><br>
> atom_start_char ::= XID_Start ∖ (Lu ∪ Lt)<br>
><br>
> atom_continue ::= XID_Continue ∪ "@"<br>
> | "." XID_Continue<br>
<br>
That will allow Latin-1 atoms that are not now legal.<br>
<br>
> General explanation<br>
> -------------------<br>
><br>
> I think the EEP could benefit from explaining more about the used character<br>
> classes, what kind of stability annex #31 is designed to give and such.<br>
><br>
> When I did read the EEP it took several days of Unicode standard reading to<br>
> start understanding, and I think many hesitate before trying to understand<br>
> the EEP, which is a pity.<br>
<br>
Well, yes. Is it my job to repeat all the material in the Unicode<br>
standard? I don't think so. I mean, the thing's telephone-book size!<br>
><br>
> My first concern was about if I write code for one Unicode Erlang release<br>
> in the future, will then that code be valid for subsequent Erlang releases<br>
> based on later Unicode standards.<br>
<br>
Yes. Section 1.1 of UAX#31 could hardly be more explicit. Well,<br>
maybe it could, which is why it points to<br>
<a href="http://www.unicode.org/policies/stability_policy.html" target="_blank">http://www.unicode.org/policies/stability_policy.html</a><br>
which says<br>
<br>
- Once a character is XID_Continue,<br>
it must continue to be so in all future versions.<br>
- If a character is XID_Start then it must also be XID_Continue.<br>
- Once a character is XID_Start,<br>
it must continue to be so in all future versions.<br>
<br>
amongst other things.<br>
<br>
> For example the EEP and my proposal both define atom_start to be XID_Start<br>
> minus a set containing uppercase and titlecase letters. XID_Start is<br>
> derived from ID_Start, and ID_Start contains Other_ID_Start. I have failed<br>
> in finding which codepoints are contained in Other_ID_Start.<br>
<br>
To start with, the purpose of Other_ID_Start is to provide stability.<br>
Any character which _used_ to be an ID_Start but because of some change<br>
would have ceased to be so will be given that property to compensate.<br>
<br>
The properties Other_ID_Start and Other_ID_Continue are listed in<br>
Proplist.txt in the Unicode data base. Here's the current set:<br>
<br>
# ================================================<br>
<br>
2118 ; Other_ID_Start # Sm SCRIPT CAPITAL P<br>
212E ; Other_ID_Start # So ESTIMATED SYMBOL<br>
309B..309C ; Other_ID_Start # Sk [2] KATAKANA-HIRAGANA VOICED SOUND MARK..KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK<br>
<br>
# Total code points: 4<br>
<br>
# ================================================<br>
<br>
00B7 ; Other_ID_Continue # Po MIDDLE DOT<br>
0387 ; Other_ID_Continue # Po GREEK ANO TELEIA<br>
1369..1371 ; Other_ID_Continue # No [9] ETHIOPIC DIGIT ONE..ETHIOPIC DIGIT NINE<br>
19DA ; Other_ID_Continue # No NEW TAI LUE THAM DIGIT ONE<br>
<br>
# Total code points: 12<br>
<br>
> But since we here define atom_start as above, moving a character from Lu<br>
> or Lt into Other_ID_Start will remove it from atom_start and old code<br>
> using it will not compile.<br>
<br>
<br>
Lu and Lt are "General Categories". Other_ID_Start is a "property".<br>
<br>
OK, now we've got a genuine technical problem.<br>
<br>
The set of characters that can begin a variable-OR-an-unquoted-atom<br>
can only grow. That much stability we're promised.<br>
<br>
If a character changes from Lu to Lt or Other_ID_Start,<br>
no problem. If a character changes from Lt to Lu or<br>
Other_ID_Start, no problem. But if a character changes<br>
from Lu/Lt to Ll/Lo or vice versa, we have a problem.<br>
<br>
Perhaps we can appeal to this:<br>
Once a character is encoded, its properties may still be<br>
changed, but not in such a way as to change the fundamental<br>
identity of the character.<br>
...<br>
For example, the representative glyph for U+0061 “A”<br>
cannot be changed to “B”; the General_Category for<br>
U+0061 “A” cannot be changed to Ll (lowercase letter)<br>
...<br>
<br>
Case Pair stability _nearly_ gives us what we want.<br>
If two characters form a case pair in a version of Unicode,<br>
they will remain a case pair in each subsequent version of Unicode.<br>
<br>
If two characters do not form a case pair in a version of Unicode,<br>
they will never become a case pair in any subsequent version of Unicode.<br>
That is, if "D" and "d" are unequal defined characters such that<br>
lower("D") = "d" and upper("d") = "D", then this will remain true.<br>
This means that<br>
If "D" is an Lu character now and "d" the corresponding Ll<br>
character, they are going to remain a case pair.<br>
So we could fiddle a bit and say<br>
Lu + Lt + Pc + (Other_ID_Start such that lower(x) != x)<br>
is what we're after.<br>
<br>
This doesn't handle the situation where there is a cased letter now<br>
but not its case opposite, as Latin-1 had y-umlaut and sharp s as<br>
lower case letters with no upper case version. But when case opposites<br>
for them did go into Unicode, they didn't change.<br>
<br>
I don't think we actually have a problem.<br>
<br>
However, the attached revision to EEP 40 has two recommendations.<br>
<br>
<br>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">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>
<br></blockquote></div>