簡體   English   中英

lisp 符號的有效字符

[英]valid characters for lisp symbols

首先,據我了解,變量標識符在普通 lisp 中稱為符號。

我注意到,雖然在 C 等語言中,變量標識符只能是字母數字和下划線,但 Common Lisp 允許使用更多字符,如“*”和(至少 scheme 是這樣)“?”

所以,我想知道的是:Common Lisp 允許在符號(或變量標識符,如果我錯了)中包含的完整字符集到底是什么? Scheme 也一樣嗎?

另外,函數名稱的字符集是否不同?

我一直在谷歌搜索,查看 CLHS 和 Practical Common Lisp,就我的生活而言,一定是出了什么問題,因為我似乎找不到答案。

詳細的答案有點棘手。 Common Lisp 有 ANSI 標准。 它定義可用字符集。 基本上你可以使用所有這些定義的字符作為符號。 另請參閱作為標記的符號

例如

|Polynom 2 * x ** 3 - 5 * x ** 2 + 10|

是一個有效的符號。 請注意,豎線標記符號,不屬於符號名稱。

然后是Common Lisp的現有實現及其對各種字符集和字符串類型的支持。 所以有幾個支持 Unicode(或類似的)並允許在符號名稱中使用 Unicode 字符。

LispWorks:

CL-USER 1 > (list 'δ 'ψ 'σ)
(δ ψ σ)

[從策划者的角度來看。 盡管 Scheme 和 Common Lisp 中的某些概念具有相同的名稱,但這並不意味着兩種語言中的含義相同。]

首先注意符號和標識符是兩個不同的東西。

符號可以被認為是支持快速相等比較的字符串。 如果兩個符號st的拼寫方式相同,則它們相等(或多或少)。 操作string=? 需要遍歷 中的字符,看看它們是否都一樣。 這花費的時間與最短字符串的長度成正比。 另一方面,符號會自動(在運行時系統中)放入(通常)哈希表中。 因此symbol=? 歸結為簡單的指針比較,因此速度非常快。 在 C 語言中使用枚舉的情況下,通常會使用符號。

符號是可以在運行時出現的值。

標識符只是程序中變量的名稱。

現在,如果要將所述程序表示為 Scheme 值,一種選擇是使用符號來表示標識符——但這並不意味着符號就是標識符(反之亦然)。 標識符的更好表示(仍在 Scheme 中)是語法對象,它除了標識符的名稱外還記錄了標識符被讀取(或構造)的位置。 假設您遇到一個未定義的變量,並且想要指示未定義變量在程序中的位置,那么源位置是標識符表示的一部分就非常方便了。

最后但並非最不重要的。 標識符的合法字符是什么? 這里最好引用R6RS的章節和版本:

4.2.4 標識符

Scheme 也可以接受其他編程語言允許的大多數標識符。 通常,當字母、數字和“擴展字母字符”的序列以不能開始表示數字對象的字符開頭時,它就是一個標識符。 此外,+、- 和... 是標識符,字母、數字和以雙字符序列 -> 開頭的擴展字母字符序列也是如此。 以下是標識符的一些示例:

 lambda q soup list->vector + V17a <= a34kTMNs ->- the-word-recursion-has-many-meanings

擴展字母字符可以在標識符中使用,就好像它們是字母一樣。 以下是擴展字母字符:

 . $ % & * + -: /? < = > ? @ ^ _ ~

此外,Unicode 標量值大於 127 且 Unicode 類別為 Lu、Ll、Lt、Lm、Lo、Mn、Mc、Me、Nd、Nl、No、Pd、Pc、Po、Sc、Sm、Sk 的所有字符, So, 或 Co 可以在標識符中使用。 此外,當通過 <inline hex escape> 指定時,可以在標識符中使用任何字符。 例如,標識符H\x65;llo與標識符Hello相同,標識符\x3BB; 與標識符λ相同。

在 Scheme 程序中,任何標識符都可以用作變量或句法關鍵字(參見 5.2 和 9.2 節)。 任何標識符也可以用作句法數據,在這種情況下它代表一個符號(參見第 11.10 節)。

來自: http ://www.r6rs.org/final/html/r6rs/r6rs-ZH-7.html#node_sec_4.2.4

請參閱 CLHS 的第 2 章,其中詳細描述了閱讀器算法。 但簡單的答案是,如果標記不是 readmacro 調用(第 2.4 節),也不是數字或所有點,它默認被解釋為符號。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM