Saturday, July 15, 2006
Schema Analysis and the need for Python-based DSLs
最近，我偶然碰到了一個有意思的項目：
“Alloy分析器是由軟件設計組（Software Design Group）開發的一個用來分析使用Alloy建立的模型的工具。Alloy是一個簡單的基於一階邏輯的結構建模語言。該工具可以生成不變式的實例、模擬操作的執行（即使是那些隱式定義的操作）和檢查一個模型的用戶指定屬性。Alloy和他的分析器起初常被用來研究抽象的軟件設計。在後續的研究項目中它還被用於分析代碼與規格說明書的一致性和作爲一個測試用例的自動生成器來使用。”
我花了一點時間仔細閱讀了其用戶手冊，發現這個語言與相關領域計算法（domain-relational calculus）十分相像。它用居於集合和關係兩者之間的形式來表現一個模式。實際上，它看起來就是一個很棒的用來設計對象模型並表達它們內在約束關係的語言。我甚至都想知道能否用一個精美的Python式語法，尋找到一種擴充表達prolog-like規則的Python食譜祕訣（Python cookbook recipe for expressing prolog-like rules）的途徑以支持Alloy的全部表達能力。
簡潔地用純Python來表現模式（expressing schemas）的最大的一個問題是你常常需要在類型定義前涉及到這些類型。例如，如果你希望FileSystemObject將Directory作爲其父類，而Directory是FileSystemObject的其中一子類，這時你就得使用一個向前引用，然而這是用今天的Python很難輕鬆表達出來的。憑藉我爲Chandler和PEAK編寫的模式定義工具來解決這個問題要麼是需要後一個類型（Directory）定義一個反向關係再鏈接到前向關係，要麼是使用字符串來引用未定義的類型。但不管使用哪種方法都不是十分令人滿意。
所以高明的食譜祕籍（cookbook recipe）的優勢就在於它只是讓一個函數體中的所有命名都具有象徵性的意思，自動地爲這些命名創建對象並在其範圍之內執行函數代碼。之後，傳統的操作符重載技術就可以從那接管過來。這就好比開發人員可以用它來這樣定義一個模式：
@schemadef foo(): + FSObject(parent = Dir) + Dir(contents = set[FSObject]) < FSObject + File < FSObject好了，如此看來結果真的不怎麼漂亮。實際上，它唯一的好處是其允許向前引用。但我打算好好研究一下Alloy相關用戶手冊，看看能否找到一個更自然一些的從其概念到Python的映射關係。與嘗試去簡明地表達類似Python中 “directory不可以是其自身的子類”一類的通用集合約束（generalized set constraints）這樣一個問題比起來，向前引用的問題實際上真的是次要的了。這都只是一些需要去實現我的關於peak.schema的烏托邦夢想（utopian dreams for peak.schema）的東西，而它們需要一個邏輯或set (mini-)語言來甄選出來。
遺憾的是，Python並非是這世界上用於創造特殊域（domain-specific）語言中的最適合的語言。在這方面Ruby確實要強於Python—這可不同於那些Ruby的狂熱愛好者們所追捧的所有所謂的優點，他們沒意識到Python早已具有那些他們都還含含糊糊說不清的基本要素。
然而，Ruby在這一方面的優點基本可歸結於兩點：無需括號括起就可以調用函數和擁有代碼塊。第一個優點很好，因爲它實現了創建命令或僞語句（pseudo-statements），第二個也有必要，因爲它使那些僞語句能夠包含代碼塊。假如至少沒有第二個特性，Python也將不再適用於重量級的DSL構建。
然而，出於考慮到人們可能寫出令人困惑的代碼的原因，塊大概是Python永遠也不會引入的一項機制了。也就是說，讓每一位程序員成爲一個語言設計者就意味着每一個程序都變成是用它自己的語言所寫的了：災難性的急劇滑向Lisp。:-)Python之所以偉大的原因之一就是它是一個簡單，易學的語言。有一點“一次學會，通讀所有（learn once, read anything）”的意思。可定製的語法意味着在其退化的情況下可以變成一種新語言，有了它你能夠理解你想要讀的任何程序。說實話我不是很確定該不該打開這些閘門，儘管它偶爾會因爲無法創建DSLs而給我帶來不便。
（原文鏈接網址：http://dirtsimple.org/2006/07/schema-analysis-and-need-for-python.html）