Oslo

2008 年 10 月 28 日

特定領域語言

Oslo 是 Microsoft 的一個專案，我們在 PDC 會議本週之前聽過許多關於它的消息，但了解的細節不多。我們所知道的是，它與 ModelDrivenSoftwareDevelopment 和 DomainSpecificLanguages 有關。

幾週前，我與語言狂熱的同事 Rebecca Parsons 搶先一睹它的真面目，我們與 Don Box、Gio Della-Libera 和 Vijaye Raji. 一起預覽了 PDC 的公開演講。那是一場非常有趣的簡報，足以讓我相信 Oslo 是值得關注的技術。它廣義上來說是一個 語言工作台。我不會在此嘗試對這個工具進行全面的回顧，而只是分享我從演練中得到的零碎印象。它確實很有趣，讓我認為我應該在此發表我的印象。隨著 PDC 的公開發布，我確定你在未來幾週會聽到更多關於它的消息。在我描述我的想法時，我會使用許多我為 我的書 開發的語言，所以你可能會覺得術語有點艱澀。

Oslo 有三個主要元件

  • 一個建模語言 (目前代號為 M) 用於文字 DSL
  • 一個設計介面 (名為 Quadrant) 用於圖形 DSL
  • 一個儲存庫 (沒有名稱) 用於將 語意模型 儲存在關聯式資料庫中。

(這些名稱都是目前的代號。行銷部門仍會使用將「Avalon 和 Indigo」替換為「WPF 和 WCF」的相同智慧。我只希望他們會將「Windows」重新命名為「Windows 技術基礎」.)

文字語言環境是自舉的，並提供三種基礎語言

  • MGrammar：定義語法導向翻譯的語法。
  • MSchema：定義語意模型的架構
  • MGraph：是一種用於表示語意模型內容的文字語言。所以 MSchema 表示類型，而 MGraph 表示實例。Lispers 可能會將 MGraph 視為具有醜陋語法的 s-expression。

你可以用 MGraph 表示任何模型，但語法通常不太好。使用 MGrammar，你可以為自己的 DSL 定義語法，這允許你使用自己的 DSL 編寫腳本，並建立一個解析器將它們轉換為更有用的東西。

使用我書中引言中的狀態機範例，你可以使用 MSchema 定義一個狀態機語意模型。然後，你可以用 MGraph 以（醜陋的方式）填充它。你可以使用 MGrammar 定義語法並驅動解析器，建立一個像樣的 DSL 來填充它。

有一個語法編譯器（稱為mg），它會採用 MGrammar 中的輸入檔案，並將其編譯成他們所謂的映像檔案，或 .mgx 檔案。這與大多數的剖析器產生器工具不同。大多數的剖析器產生器工具會採用語法並產生必須編譯成剖析器的程式碼。相反地，Oslo 的工具會將語法編譯成剖析規則的二進位形式。接著有一個獨立的工具（mgx），它可以採用輸入指令碼和編譯的語法，並輸出輸入指令碼的語法樹的 MGraph 表示法。

更可能的是，您可以採用編譯的語法，並將其新增到自己的程式碼中作為資源。有了這個，您可以呼叫 Oslo 提供的通用剖析器機制，作為 .NET 架構，提供編譯的語法檔案的參考，並產生記憶體中的語法樹。接著您可以瀏覽這個語法樹，並使用它來執行任何您想要執行的動作 - 我稱之為樹狀結構的剖析策略。

剖析器會提供語法樹給您，但這通常與語意模型不同。因此，您通常會撰寫程式碼來瀏覽樹狀結構，並使用 MSchema 定義的語意模型來填入資料。完成這個步驟後，您可以輕鬆地採用該模型，並將其儲存在儲存庫中，以便透過 SQL 工具存取。他們的示範展示了透過 DSL 輸入一些資料，並存取儲存庫中對應的表格，儘管我們沒有深入探討複雜的結構。

您也可以使用 Quadrant 來操作語意模型實例。您可以為架構定義圖形符號，然後系統可以投影模型實例，使用該符號建立圖表。您也可以變更圖表，這會更新模型。他們展示了模型的兩個圖形投影的示範，使用觀察者同步更新其中一個，並更新另一個。以這種方式使用 Quadrant 看起來類似於圖形語言工作台，例如MetaEdit的工作方式。

在他們開發 Oslo 的過程中，他們一直在其他 Microsoft 專案中使用它，以獲得使用它的經驗。到目前為止，主要專案包括 ASP、工作流程和網路服務。

更多關於 M

我們花費大部分時間檢視文字環境。他們有一種方法可以將編譯的語法連接到文字編輯控制項，以提供具有各種完成和突顯功能的語法感知文字編輯器。然而，與MPS等工具不同，它仍然是一個文字編輯器。因此，您可以自由地剪下和貼上文字區塊，並操作文字。如果您所執行的動作有剖析問題，該工具會提供波浪線給您，但它會保留編輯文字的體驗。

我想我喜歡這個。當我第一次遇到它時，我相當喜歡 MPS 的概念：「它看起來像文字，但實際上是一個結構化的編輯器」。但最近我開始認為我們這樣會失去很多，所以 Oslo 的工作方式很有吸引力。

他們擁有的另一個不錯的文字語言工具是幫助撰寫 MGrammars 的編輯器。這是一個分成三個垂直窗格的視窗。中央窗格包含 MGrammar 程式碼，左窗格包含一些輸入文字，而右窗格顯示使用 MGrammar 分析輸入文字的 MGraph 表示。它非常以範例為導向。（然而，它與測試不同，是暫時的。）該工具類似於 Antlr 中使用語法立即處理範例文字的功能。在對話中，Rebecca 將這種風格稱為「軼事測試」，這是一個我必須記住要偷的詞彙。

他們使用的分析演算法是 GLR 分析器。語法語法類似於 EBNF，並有樹狀結構表達式的符號。他們在詞法分析器中使用自己的正則表示法變體，以與其其他工具保持一致，這可能會讓像我這樣更習慣 ISO/Perl 正則表示法的人感到困擾。它大多數類似，但不同之處足以令人煩惱。

他們語法符號的一個不錯的功能是，他們提供了建構體，可以輕鬆建立參數化規則，有效地允許您撰寫規則子常式。規則也可以給予屬性（又稱註解），類似於 .NET 的語言屬性。因此，您可以透過標記屬性來使整個語言不區分大小寫。（有趣的是，他們使用「@」來標記屬性，就像 Java 語法一樣。）

執行語法預設的方式是進行樹狀結構建立。事實證明，樹狀結構建立是預設類別的行為，該類別在處理一些輸入時會被語法呼叫。這個類別有一個介面，您可以撰寫自己的類別來實作這個介面。這將允許您進行嵌入式翻譯和嵌入式詮釋。它與程式碼動作不同，因為動作程式碼不在語法中，而是在這個其他類別中。我認為這可能會更好，因為動作中的程式碼常常會淹沒語法。

他們討論了一些將一種語言嵌入另一種語言並優雅地切換分析器以處理此問題的能力，這進入 Converge 已探索的領域。我們沒有深入探討這一點，但這會很有趣。

他們提到的一個有趣的趣聞是，他們原本打算只擁有圖形語言的工具。然而，他們發現圖形語言對於許多問題來說並不好用，包括定義架構。因此，他們開發了文字工具。

（以下是給行銷部門的建議。如果您堅持使用「M」這個名稱，您可以使用 這部優秀的電影 作為行銷靈感 ;-))

比較

顯然，這個工具與我 2005 年稱為語言工作台的工具，例如 Intentional Software 和 JetBrains MPS，處於相同的空間。Oslo 並不完全符合我當時給出的語言工作台定義。特別是，文字元元件並非投影式編輯器，而且您不必使用基於抽象表示（語意模型）的儲存表示，而可以將文字來源儲存在更傳統的樣式中。這種較不依賴於持續抽象表示的方式類似於 Xtext。在某個時間點，我確實需要重新思考我認為語言工作台的定義元素是什麼。目前，我們只說 Xtext 和 Oslo 感覺像是語言工作台，直到我重新檢視定義，我將它們視為語言工作台。

此比較中特別有趣的一點是將 Oslo 與 Microsoft 的 DSL 工具 進行比較。它們是不同的工具，有很多重疊之處，這讓您不禁懷疑是否有它們的容身之處。我聽過含糊的「它們配合得很好」的說法，但尚未信服。這可能是大公司中常見的情況，其中開發了多個半競爭專案。最終，這可能會導致其中一個專案被擱置。但很難對此進行推測，因為這在很大程度上取決於企業政治，因此幾乎不可能從任何人那裡得到明確的答案（即使您得到了，也很難判斷它是否是一個明確的答案）。

Oslo 與其表親共有的關鍵元素是，它提供了一個工具包來定義新語言、將它們整合在一起，並為這些語言定義工具。因此，您可以獲得外部 特定領域語言 的語法自由，並具備良好的工具 - 這解決了外部 DSL 的主要缺點之一。

Oslo 支援文字和圖形 DSL，並且似乎相當平均地執行此操作（儘管我們在文字上花費了更多時間）。在這方面，它似乎提供了比 MPS 和 Intentional（結構化文字）以及 MetaEdit/Microsoft 的 DSL 工具（圖形）更多的變化。它在文字支援方面也有所不同，因為它提供真正的自由文字輸入，而不是 Intentional/MPS 的高度結構化文字輸入。

使用編譯語法並將其插入文字編輯器，對我來說似乎是支援輸入 DSL 腳本的很好途徑。其他工具需要您擁有完整的語言工作台機制或使用程式碼產生來建立編輯器。傳遞我可以插入編輯器的語法表示，對我來說似乎是一個很好的方法。當然，如果那個語言工作台是開源的（據我所知 MPS 將會是），那麼這可能會讓這個問題變得無關緊要。

將此類內容儲存在儲存庫中的一項重大問題在於處理版本控制。我們都可以在單一共用資料庫上進行協作（道德上等同於團隊在共用磁碟機上編輯其程式碼的單一副本）的概念在我看來近乎不負責任。因此，我傾向於對建議此方法的任何廠商抱持懷疑態度。奧斯陸團隊明智地建議，將文字檔視為具有權威性的來源，這可讓您使用常規版本控制工具。當然，對許多 Microsoft 商店而言，壞消息在於此工具是 TFS（或，天哪，VSS），但使用純文字檔作為來源的一大優點在於，您可以使用眾多版本控制系統中的任何一個來儲存它。

我喜歡的一般性事物是，大多數工具傾向於執行時期詮釋，而不是程式碼產生和編譯。傳統上，剖析器產生器和許多語言工作台假設您將從模型產生程式碼，而不是詮釋它們。程式碼產生很好，但它總是讓人覺得很混亂，而且往往會導致各種讓您絆倒的方法。因此，我確實比較喜歡執行時期重點。

只有幾個小時，所以我無法對奧斯陸做出任何深遠的判斷。不過，我可以說它看起來像是一些非常有趣的技術。我喜歡它的原因在於，它似乎提供了使用語言工作台的良好途徑。有 Microsoft 在背後會是一件大事，儘管我們確實需要記住，關於 Longhorn 的各種承諾從未實現。但總體而言，我認為這是語言工作台場景中一個有趣的補充，而且是一個可以讓 DSL 更為普遍的工具。