EEP 40：Erlang 中 Unicode 變數和原子名稱的提案 #

摘要 #

本 EEP 提案如何在 Erlang 中擴展變數和原子名稱，使其能以向後相容的方式包含 Unicode 字元。

考量 #

1. 對 Unicode 的支援持續增加，並且即將出現對原始碼的最小支援。
2. Unicode 變數名稱和未加引號的原子尚未出現，現在是確定設計的時候了。
3. 它們勢必會出現。可能會有法律或機構上的理由，需要支援 Unicode 的語言。有些人只是想使用他們自己的語言和文字。Erlang 在網路應用程式方面的優勢意味著，能夠將國際化域名表示為未加引號的原子，就像能夠表示 ASCII 域名（如 www.example.com，在 Erlang 中不需要引號）一樣方便。
4. 在 UAX#31 中有一個 Unicode 識別符號的框架，許多程式語言都使用它，包括 Ada、Java、C++、C、C#、Javascript 和 Python（Python Lexical 的 2.3 節，另請參閱 PEP 3131）。
5. 現有的 Erlang 識別符號應保持有效，包括包含 “@” 和 “.” 的識別符號。
6. 現有的 Erlang 支援功能，例如在報告單例變數時忽略以底線開頭的變數，不應被破壞。
7. 我們不應「竊取」任何字元來用作變數的「魔術標記」，因為它們可能需要用於其他目的。一個好的（壞）例子是「?」，如果它不被用於巨集，則可以用於多種用途。
8. 現在不是合法的變數或原子名稱的 Latin-1 字元序列，不應透過此規範將其變成合法的名稱。

參考 #

字元集名稱，XID_Start、XID_Continue、Lu、Lt、Lo、Pc、Other_Id_Start，取自 Unicode 和 UAX#31。

Lu = upper case letters
Lt = title case letters
Ll = lower case letters
Lo = non-case letters (Arabic, Chinese, and so on)
Pc = connector punctuators, including the low line (_) and
     a number of other characters like undertie (‿).
Other_Id_Start = script capital p, estimated symbol,
     katakana-hiragana voiced sound mark, and
     katakana-hiragana semi-voiced sound mark.

規範 #

變數 #

variable ::= var_start var_continue*

var_start ::= (XID_Start ∩ (Lu ∪ Lt ∪ Other_Id_Start)) ∪ Pc

var_continue ::= XID_Continue ∪ "@" \ "ªº"

此處的 XID 選擇遵循 Python。它確保變數的正規化仍然是一個變數。事實上，Unicode 變數應被正規化。Unicode 有足夠多看起來相似的字元，我們不能指望「看起來相同 <=> 相同」為真，但我們應該朝這個方向邁進一步。

在不區分字母大小寫的腳本中，變數必須以某些特殊字元開頭，以確保它們不會被誤認為是未加引號的原子。在基本多語言平面中，有 10 個 Pc 字元。Erlang 解析器會特殊處理以底線開頭的變數：如果它是單例，則不會有任何抱怨。一種方法是說這種特殊處理不適用於其他 9 個 Pc 字元。使用這種方法，‿ 不會是萬用字元，_隠者 應該是單例，而 ‿隠者 不應該是。

當然，有人可能會使用包含阿拉伯字母但不包含底線的字體。我們可以透過修改底線規則來處理這個問題，我建議這樣做

Variable does not begin with a Pc character =>
         should not be a singleton.

Variable is just a Pc character and nothing else =>
         is a wild card.

Variable begins with a Pc character followed by an
Lu or Lt or Pc character =>
         may be a singleton.

Variable begins with a Pc character followed by
a legal character other than an Lu or Lt or Pc character =>
         should not be a singleton.

因此，‿ 是萬用字元，隠者 是一個原子，_隠者 不應該是單例，但 __隠者 *可能* 是單例。此規則是現有規則的一致性概括。

未加引號的原子 #

unquoted_atom ::= "."? atom_start atom_continue*

atom_start ::= XID_Start \ (Lu ∪ Lt ∪ "ªº")

atom_continue ::= XID_Continue ∪ "@" \ "ªº"
               |  "." atom_start

同樣，XID 的選擇遵循 Python，並確保未加引號的原子的正規化仍然是一個未加引號的原子。未加引號的原子應被正規化。

Erlang 未加引號的原子的細節有些微妙；我已經透過實驗檢查了我的理解。允許使用初始點，但始終會被捨棄。這很奇怪，但現在就是這樣。

關鍵字 #

關鍵字具有未加引號的原子形式。不會引入新的關鍵字。

具體細節 #

• 任何 Python 識別符號或關鍵字都是 Erlang 變數或未加引號的原子或關鍵字，除非它包含 “ª” 或 “º”。

• @ 符號可以自由地出現在變數和未加引號的原子中，但不能作為第一個字元，就像現在一樣。

• 雖然它們在 Ll 集中，因此在技術上是小寫字母，但 “ª” 和 “º” 不允許在此提案中的變數名稱或未加引號的原子中使用，因為它們現在在 Erlang 中不允許使用。

• 點後面不能跟隨大寫字母、數字或底線，就像現在一樣。

• 我不確定是否應該允許在點之後使用修飾字母。

• 我不確定如何處理 Other_ID_Start 字元。Script capital p 看起來像大寫的 p，甚至在它的名稱中帶有「capital」。所有其他的「* SCRIPT CAPITAL *」字元都是大寫字母。當然應該允許它作為變數的開頭。估計符號看起來像一個放大的小寫 e；其他看起來像字母的符號被歸類為字母。您會期望它作為原子的開頭。至於片假名-平假名濁音符號，我完全沒有直覺。將整個群組分配給原子似乎是最安全的。

• 所有現有的變數名稱和未加引號的原子仍然合法，並且沒有引入任何僅使用 Latin-1 字元的新的變數或原子形式。

理由 #

雖然旨在與廣大受眾共享的 Erlang 檔案仍應以英文編寫，但如果人們在一個精通某種語言的小組中工作，而需求也以該語言編寫，則他們應該能夠保持與需求術語的接近，以免引入翻譯錯誤。

整個設計的方向是「如果有人想在 Erlang 檔案中使用自己的腳本，他們應該能夠以一種與其他程式語言普遍一致的方式輕鬆地做到這一點。」

這確實意味著會有一些 Erlang 原始碼檔案，熟練的 Erlang 程式設計師因為不熟悉腳本而無法破譯。在 Unicode 6 中有超過 110,000 個字元，無論我們做什麼，這都必然會發生。一旦 Unicode 字串可用，帶引號的 Unicode 原子會遠遠落後嗎？一旦它們成為可能，拒絕未加引號的 Unicode 原子並不能挽救普遍的可讀性。它只會透過要求大量使用單引號來惹惱人們。老 Algol 程式設計師會清楚地記得單引號的暴風雨對可讀性造成的損害有多大。如果你可以使用 γαμμα 作為原子，那麼拒絕 Γαμμα 有任何意義嗎？

此 EEP 的目標之一是，如果 Erlang 文字僅包含 Latin-1 字元，則在新規則下應該是合法的，當且僅當它在舊規則下是合法的，並且在任何一種情況下都應該具有相同的含義。在過渡期間，會有人為遵循新規則的系統編寫 Erlang 程式碼，並將其提供給使用 Latin-1 或至少是舊規則系統的人。他們不應意外地引入不相容性。這就是為什麼我們現在必須禁止使用 “ª” 和 “º”。稍後我們可能會取消該禁令。

我們必須透過三種方式來自訂 UAX 31 定義。

• 我們必須繼續支援變數中的 “@” 以及未加引號的原子中的 “@” 和 “.”，以實現向後相容性。

• 我們必須繼續禁止包含 Latin-1 陽性和陰性序數指示符的未加引號的原子。

• 我們必須區分變數和未加引號的原子。

我們可能會透過第四種方式來自訂它。Unicode 的 Ken Whistler 建議，除非有舊版原因需要支援其他內容，否則他「認為沒有太多意義」允許 LOW LINE 和 FULLWIDTH LOW LINE 以外的 Pc 字元。如果 s 是合法的 ASCII 識別符號，那麼 s 的全寬版本也應該是合法的識別符號，這似乎是一個好主意，所以絕對應該允許 FULLWIDTH LOW LINE。我發現使用 UNDERTIE 很酷，但它實際上是一個編輯器的標記。如果我們現在拒絕其他 Pc 字元，如果我們發現有需要，我們總是可以稍後允許它們；如果我們現在允許它們，則稍後很難拒絕它們。清楚地在定義中進行此變更需要一點思考，因此這是針對下一個修訂版本的。

Dmitry Belyaev 提出了本地化關鍵字的問題。這不在本 EEP 的範圍之內，本 EEP 關心的是哪些字元序列是變數，哪些是關鍵字或未加引號的原子。在我們可以考慮本地化關鍵字之前，必須先弄清楚這一點。

根據 Ulrich Neumerkel 的建議，於 11 月 5 日修改了開頭底線規則，以避免 _Œuvre 不會被接受為單例的問題。現在它可以了。這很諷刺，因為毛利語變數（如 _Āporo）會被錯誤分類。

問題點 #

非常希望即使在 Unicode 修訂時，合法的 Erlang 文字也應該保持合法。UAX#31 和 穩定性幾乎給了我們需要的東西。唯一看起來技術上可行的問題是，沒有相反大小寫對應的大寫或小寫字母可能會變更其一般類別（如果它完全停止作為字母，則會被賦予 Other_ID_Start 屬性），因此，以此類大小寫孤兒開頭的識別符號可能會從變數切換到未加引號的原子，反之亦然。一些大小寫孤兒確實存在，例如 LATIN LETTER SMALL CAPITAL M，但是大寫的大寫 M 會是什麼？

一種可能性是向 Unicode 聯盟提出這個問題，並在他們回覆之前保持未解決狀態。該問題已經被提出，並且初步回覆「您可能無法依賴任何給定標準屬性進行特殊用途。特別是如果該屬性不是正式穩定的。」給出。下一步可能是在 UAX#31 中尋求修訂，因為 Erlang 並非唯一需要區分大小寫的程式語言。

另一種可能性是說，Lu 字元只有在具有小寫對應項時才能作為變數的開頭，而 Ll 字元只有在具有大寫對應項時才能作為未加引號的原子的開頭。由於 “ß” 和 “ÿ” 在 Unicode 中具有大寫對應項，因此 Latin-1 未加引號的原子不受此類規則的影響。大多數 Lo 字元也不會受到影響。

版權 #

本文檔已置於公共領域。