Apocalypse #1 中引入的“語義模型”是什么？

Question

在啟示錄 #1中，拉里寫道，我特別強調：

Raku 將支持 map 到單個語義 model 的多種語法。 其次，單一語義 model 將依次 map 到多個平台。

我對拉里在寫“單一語義模型”時可能意味着什么有一些模糊的概念：

• 圖靈完備語言/自動機； 和/或

• 什么變成了6model； 和/或

• 什么變成了 NQP/nqp。

（我用谷歌搜索並發現了一些討論，例如slashdot 上的這個，但它們同樣含糊不清。）

也許比回答他當時的想法更重要的是已經發生的事情。

他的表述聽起來很像 map 到NQP 和/或 nqp （在 Raku / NQP/nqp / NQP 后端架構的中間）。

（如果是這樣，大概 model 被 nqp 的“指定”等同於 Raku 的烤肉？）

或者，根據 Liz++、QAST 或 RAST？

---

我知道我認為誰能夠最好地回答我的主要問題（在標題中），但也許其他人知道？

Answer 1

Apocalypse #1 代表了 Larry 在將我們引向我們今天所知道的 Raku 語言的過程中的一些最早的想法。 我在語言設計過程中並沒有那么早，所以我給出的任何答案自然都會涉及嘗試想象當時已知的內容。 有了這個相當重要的警告，讓我們來看看。

語法是關於我們編寫的單詞和符號的。 語義是關於事物的含義。 例如，假設我們使用的語言具有中綴運算符之類的東西，並且有一個拼寫為+的運算符。 我們可以寫出表達式a + b 。 語義告訴我們它的含義。 盡管許多編程語言都具有這種語法，但它們在與之相關的語義（即含義）方面存在巨大差異。 例如：

• 在 C 中，它取決於a和b的類型。 這可能意味着某種數字加法（基於 integer、integer 秩、浮點等的一大堆規則）。 但是，如果a是一個指針， b是一個 integer，那么實際上也有一個基於指針大小的偷偷摸摸的乘法。
• 在 C++ 中，請參見 C 中的定義，但也可能是對運算符重載的 function 調用，和/或在應用操作數轉換規則后獲得的任何操作數轉換規則。 請不要問我這些規則是什么。
• 在 Java 中，它也按類型進行； 它可能意味着數字加法，也可能意味着字符串連接。
• 在 JavaScript 中，可能是數字加法或字符串連接，但它是在運行時根據規則決定的。 不，也不要問我這些。
• 在 Raku 中，它是對infix:<+>的 function 調用，這意味着無論標准庫決定它意味着什么。

對我來說，語義 model 是描述語義的系統方式。 這可能作為以下一項或多項存在：

• 試圖描述應該做什么的書面（自然語言）規范
• 一個可執行的規范，試圖描述事物的行為（如 Raku 規范測試）
• 使用數學形式的語義表達，例如操作語義或指稱語義
• 用其他語言實現的解釋器（在這種情況下，我們依靠它的語義模型）
• 翻譯成其他語言的編譯器（同樣，我們依靠目標語言的語義 model）

正如我們已經觀察到語法a + b可能 map 到不同語言的許多不同語義一樣，我們也可以將許多語法映射到同一組語義。 即使在標准 Raku 中也是如此。 編寫$a + $b和infix:<+>($a, $b)之間沒有語義差異。

雖然這可能提供了一些答案，但閱讀您引用的段落之后的段落很有趣。 以下是附注的內容。

多種語法聽起來像是一件壞事，但它們對於語言的發展確實是必要的。

我認為“進化”的使用在這里很重要，因為允許語言的語法以受控方式改變，事實上，允許語言語法的不同突變共存。 此外，可以應用適者生存（適合的可能是使用該語言的上下文的 function）。 給定語法是語言的接口，例如，值得霍夫曼化的東西可以隨時間或上下文變化，期望它可能會發展並不是不合理的，同時仍然提供對相同底層行為集的訪問。

無論如何，我認為我們可以將其視為預見用戶定義的運算符和俚語等功能。

在某種程度上我們在 Perl 5 中已經有了一個多語法 model； 每次您使用編譯指示或模塊時，您都在扭曲您正在使用的語言。

我覺得這部分有點奇怪，因為“語言”不僅僅是語法，也是語義，實際上很多 pragma 改變語義而不是（只是）語法。 另一方面，它確實說“在某種程度上”，這是一個很好的躲在后面的對沖。 :-)

只要從模塊頂部的聲明中清楚您正在使用哪個版本的語言，這不會造成什么問題。

這意味着語言突變是范圍內的事情。 它們最終是詞法范圍的，而不僅僅是文件范圍的。 這並不完全令人驚訝。 在設計過程中似乎越來越意識到詞匯范圍的實用性。

支持多種語法將如何實現持續發展的一個特別有力的例子是從 Perl 5 遷移到 Perl 6 本身。

這表明當時的想法是 Perl 5 和 Perl 6（現在的 Raku）有足夠的共同點，它們可以共享語義 model，並運行相同的運行時。 正如我們所知，事情並沒有這樣發展，但是在寫《啟示錄》#1 時，我可以想象這是一個假設。 事實上，它可能會在很長一段時間內保持不變。 例如，PONIE（嘗試在 Parrot VM 上運行 Perl 5 的項目）在幾年后仍在進行中。

實際上，隨着語言設計的出現，原本允許這樣做的單一語義 model 變得不切實際。 出於這個原因，將 Perl 6 的功能引入 Perl 5 的各種努力都在掙扎。 智能匹配是這方面的典型代表，問題根本不是因為語法，而是因為語義：在 Raku 中，事物總是知道它們的類型，而在 Perl 5 中，標量可能同時包含字符串和數字表示，取決於該值在此之前的使用方式。 該功能基於 Raku 語義 model 中的某些內容，而在 Perl 5 語義 model 中沒有直接等效項。

另一個有趣的地方是，目前正在進行的 RakuAST 工作將提供 Raku 語言的文檔 object model 形式。 我們可以將此視為 Raku 的另一種語法，表示為 object 圖。 鑒於它也是編譯器前端用於 Raku 代碼的表示形式，我們也可以將其視為 Raku 語義 model 的一種與語法無關的網關。 而且，當我們真正擁有俚語時，可以預期它們將通過將與附加俚語語法相關的語義表達為 RakuAST 節點的組合來實現——因此最終將根據單個 Raku 提供新語法語義 model。