用Python建立聲明性迷你語言的教程

大多數程式員考慮編程時，他們都要設想用於編寫應用程式的 命令式樣式和技術。最受歡迎的通用程式設計語言（包括 Python 和其它物件導向的語言）在樣式上絕大多數都是命令式的。另一方面，也有許多程式設計語言是 聲明性樣式，包括函數語言和邏輯語言，還包括通用語言和專用語言。

讓我們列出幾個屬於各個種類的語言。許多讀者已經使用過這些工具中的許多工具，但不見得考慮過它們之間的種類差別。Python、C、C++、Java、Perl、Ruby、Smalltalk、Fortran、Basic 和 xBase 都是簡單的命令式程式設計語言。其中，一些是物件導向的，但那隻是組織代碼和資料的問題，而非基本編程樣式的問題。使用這些語言，您 命令程式執行指令序列：把某些資料 放入（put）變數中；從變數中 擷取（fetch）資料； 迴圈（loop）一個指令塊 直到（until）滿足了某些條件； 如果（if）某個命題為 true，那麼就進行某些操作。所有這些語言的一個妙處在於：便於用日常生活中熟悉的比喻來考慮它們。日常生活都是由做事、選擇、再做另一件事所組成的，期間或許會使用一些工具。可以簡單地將運行程式的電腦想象成廚師、瓦匠或汽車司機。

諸如 Prolog、Mercury、SQL、XSLT 這樣的語言、EBNF 文法和各種格式的真正設定檔，都 聲明某事是這種情況，或者應用了某些約束。函數語言（比如 Haskell、ML、Dylan、Ocaml 和 Scheme）與此相似，但是它們更加強調陳述編程對象（遞迴、列表，等等）之間的內部（函數）關係。我們的日常生活（至少在敘事品質方面）沒有提供對這些語言的編程構造的直接類比。然而，對於那些可以用這些語言進行描述的問題來說，聲明性描述 遠遠比命令式解決方案來得簡明且不易出錯。例如，請研究下面這個線性方程組：
清單 1. 線性方程式系統樣本

10x + 5y - 7z + 1 = 017x + 5y - 10z + 3 = 05x - 4y + 3z - 6 = 0

這是個相當漂亮的說明對象（x、y 和 z）之間幾個關係的簡單運算式。在現實生活中您可能會用不同的方式求出這些答案，但是實際上用筆和紙“求解 x”很煩，而且容易出錯。從調試角度來講，用 Python 編寫求解步驟或許會更糟糕。

Prolog 是與邏輯或數學關係密切的語言。使用這種語言，您只要編寫您知道是正確的語句，然後讓應用程式為您得出結果。語句不是按照特定的順序構成的（和線性方程式一樣，沒有順序），而且您（程式員或使用者）並不知道得出的結果都採用了哪些步驟。例如：
清單 2. family.pro Prolog 樣本

/* Adapted from sample at:This app can answer questions about sisterhood & love, e.g.:# Is alice a sister of harry??-sisterof( alice, harry )# Which of alice' sisters love wine??-sisterof( X, alice ), love( X, wine)*/sisterof( X, Y ) :- parents( X, M, F ),          female( X ),          parents( Y, M, F ).parents( edward, victoria, albert ).parents( harry, victoria, albert ).parents( alice, victoria, albert ).female( alice ).loves( harry, wine ).loves( alice, wine ).

它和 EBNF（擴充巴科斯範式，Extended Backus-Naur Form）文法聲明並不完全一樣，但是實質相似。您可以編寫一些下面這樣的聲明：
清單 3. EBNF 樣本

word    := alphanums, (wordpunct, alphanums)*, contraction?alphanums  := [a-zA-Z0-9]+wordpunct  := [-_]contraction := "'", ("clock"/"d"/"ll"/"m"/"re"/"s"/"t"/"ve")

如果您遇到一個單詞而想要表述其看上去 可能會是什麼，而實際上又不想給出如何識別它的序列指令，上面便是個簡練的方法。Regex與此相似（並且事實上它能夠滿足這種特定文法產品的需要）。

還有另一個聲明性樣本，請研究描述有效 XML 文檔方言的文件類型聲明：
清單 4. XML 文件類型聲明

和其它樣本一樣，DTD 語言不包含任何有關如何識別或建立有效 XML 文檔的指令。它只描述了如果文檔存在，那它會是怎麼樣的。聲明性語言採用虛擬語氣。
Python 作為解譯器 vs Python 作為環境

Python 庫可以通過兩種截然不同的方式中的一種來利用聲明性語言。或許更為常用的技術是將非 Python 聲明性語言作為資料來解析和處理。應用程式或庫可以讀入外部來源（或者是內部定義的但只用作“blob”的字串），然後指出一組要執行的命令式步驟，這些步驟在某種形式上與那些外部聲明是一致的。本質上，這些類型的庫是“資料驅動的”系統；聲明性語言和 Python 應用程式執行或利用其聲明的操作之間有著概念和範疇差別。事實上，相當普遍的一點是，處理那些相同聲明的庫也被用來實現其它程式設計語言。

上面給出的所有樣本都屬於第一種技術。庫 PyLog 是 Prolog 系統的 Python 實現。它讀取像樣本那樣的 Prolog 資料檔案，然後建立 Python 對象來對 Prolog 聲明 建模。EBNF 樣本使用專門變體 SimpleParse ，這是一個 Python 庫，它將這些聲明轉換成可以被 mx.TextTools 所使用的狀態表。 mx.TextTools 自身是 Python 的擴充庫，它使用底層 C 引擎來運行儲存在 Python 資料結構中的代碼，但與 Python 本質上幾乎沒什麼關係。對於這些任務而言，Python 是極佳的 粘合劑，但是粘合在一起的語言與 Python 差別很大。而且，大多數 Prolog 實現都不是用 Python 編寫的，這和大多數 EBNF 解析器一樣。

DTD 類似於其它樣本。如果您使用象 xmlproc 這樣的驗證解析器，您可以利用 DTD 來驗證 XML 文檔的方言。但是 DTD 的語言並不是 Python 式的， xmlproc 只將它用作需要解析的資料。而且，已經用許多程式設計語言編寫過 XML 驗證解析器。XSLT 轉換與此相似，也不是特定於 Python 的，而且像 ft.4xslt 這樣的模組只將 Python 用作“粘合劑”。

雖然上面的方法和上面所提到的工具（我一直都在使用）都沒什麼 不對，但如果 Python 本身是聲明性語言的話，那麼它可能會更精妙，而且某些方面會表達得更清晰。如果沒有其它因素的話，有助於此的庫不會使程式員在編寫一個應用程式時考慮是否採用兩種（或更多）語言。有時，依靠 Python 的自省能力來實現“本機”聲明，既簡單又管用。

自省的魔力

解析器 Spark 和 PLY 讓使用者 用 Python 來聲明 Python 值，然後使用某些魔法來讓 Python 運行時環境進行解析配置。例如，讓我們研究一下與前面 SimpleParse 文法等價的 PLY 文法。 Spark 類似於下面這個樣本：
清單 5. PLY 樣本

tokens = ('ALPHANUMS','WORDPUNCT','CONTRACTION','WHITSPACE')t_ALPHANUMS = r"[a-zA-Z0-0]+"t_WORDPUNCT = r"[-_]"t_CONTRACTION = r"'(clock|d|ll|m|re|s|t|ve)"def t_WHITESPACE(t):  r"\s+"  t.value = " "  return timport lexlex.lex()lex.input(sometext)while 1:  t = lex.token()  if not t: break

我已經在我即將出版的書籍 Text Processing in Python 中編寫了有關 PLY 的內容，並且在本專欄文章中編寫了有關 Spark 的內容（請參閱 參考資料以擷取相應連結）。不必深入瞭解庫的詳細資料，這裡您應當注意的是：正是 Python 綁定本身配置瞭解析（在這個樣本中實際是詞法分析/標記化）。 PLY 模組在 Python 環境中運行以作用於這些模式聲明，因此就正好非常瞭解該環境。

PLY如何得知它自己做什麼，這涉及到一些非常奇異的 Python 編程。起初，中級程式員會發現可以查明 globals() 和 locals() 字典的內容。如果聲明樣式略有差異的話就好了。例如，假想代碼更類似於這樣：
清單 6. 使用匯入的模組名稱空間

import basic_lex as __.tokens = ('ALPHANUMS','WORDPUNCT','CONTRACTION')_.ALPHANUMS = r"[a-zA-Z0-0]+"_.WORDPUNCT = r"[-_]"_.CONTRACTION = r"'(clock|d|ll|m|re|s|t|ve)"_.lex()

這種樣式的聲明性並不差，而且可以假設 basic_lex 模組包含類似下面這樣的簡單內容：
清單 7. basic_lex.py

def lex():  for t in tokens:    print t, '=', globals()[t]

這會產生：

% python basic_app.pyALPHANUMS = [a-zA-Z0-0]+WORDPUNCT = [-_]CONTRACTION = '(clock|d|ll|m|re|s|t|ve)

PLY 設法使用堆疊框架資訊插入了匯入模組的名稱空間。例如：
清單 8. magic_lex.py

import systry: raise RuntimeErrorexcept RuntimeError:  e,b,t = sys.exc_info()  caller_dict = t.tb_frame.f_back.f_globalsdef lex():  for t in caller_dict['tokens']:    print t, '=', caller_dict['t_'+t]

這產生了與 basic_app.py 樣本所給輸出一樣的輸出，但是具有使用前面 t_TOKEN 樣式的聲明。

實際的 PLY 模組中要比這更神奇。我們看到用模式 t_TOKEN 命名的標記實際上可以是包含了Regex的字串，或是包含了Regex文檔字串和作業碼的函數。某些類型檢查允許以下多態行為：
清單 9. polymorphic_lex

# ...determine caller_dict using RuntimeError...from types import *def lex():  for t in caller_dict['tokens']:    t_obj = caller_dict['t_'+t]    if type(t_obj) is FunctionType:      print t, '=', t_obj.__doc__    else:      print t, '=', t_obj

顯然，相對於用來玩玩的樣本而言，真正的 PLY 模組用這些已聲明的模式可以做更有趣的事，但是這些樣本示範了其中所涉及的一些技術。

繼承的魔力

讓支援庫到處插入並操作應用程式的名稱空間，這會啟用精妙的聲明性樣式。但通常，將繼承結構和自省一起使用會使靈活性更佳。

模組 gnosis.xml.validity 是用來建立直接映射到 DTD 產品的類的架構。任何 gnosis.xml.validity 類 只能用符合 XML 方言有效性約束的參數進行執行個體化。實際上，這並不十分正確；當只存在一種明確的方式可將參數“提升”成正確類型時，模組也可從更簡單的參數中推斷出正確類型。

由於我已經編寫了 gnosis.xml.validity 模組，所以我傾向于思考其用途自身是否有趣。但是對於本文，我只想研究建立有效性類的聲明性樣式。與前面的 DTD 樣本相匹配的一組規則／類包括：
清單 10. gnosis.xml.validity 規則聲明

from gnosis.xml.validity import *class figure(EMPTY):   passclass _mixedpara(Or):   _disjoins = (PCDATA, figure)class paragraph(Some):  _type = _mixedparaclass title(PCDATA):   passclass _paras(Some):    _type = paragraphclass chapter(Seq):    _order = (title, _paras)class dissertation(Some): _type = chapter

您可以使用以下命令從這些聲明中建立出執行個體：

ch1 = LiftSeq(chapter, ("1st Title","Validity is important"))ch2 = LiftSeq(chapter, ("2nd Title","Declaration is fun"))diss = dissertation([ch1, ch2])print diss

請注意這些類和前面的 DTD 非常匹配。映射基本上是一一對應的；除了有必要對嵌套標記的量化和交替使用中介體之外（中介體名稱用前置底線標出來）。

還要注意的是，這些類雖然是用標準 Python 文法建立的，但它們也有不同尋常（且更簡練）之處：它們沒有方法或執行個體資料。單獨定義類，以便從某架構繼承類，而該架構受到單一的類屬性限制。例如， 是其它標記序列，即 後面跟著一個或多個 標記。但是為確保在執行個體中遵守約束，我們所需做的就是用這種簡單的方式來 聲明chapter 類。

編寫像 gnosis.xml.validity.Seq 這樣的父類程式所涉及的主要“技巧”，就是在初始化期間研究 執行個體的 .__class__ 屬性。類 chapter 自身並不進行初始化，因此調用其父類的 __init__() 方法。但是傳遞給父類 __init__() 的 self 是 chapter 的執行個體，而且 self 知道 chapter。為了舉例說明這一點，下面列出了部分 gnosis.xml.validity.Seq 實現：
清單 11. 類 gnosis.xml.validity.Seq

class Seq(tuple):  def __init__(self, inittup):    if not hasattr(self.__class__, '_order'):      raise NotImplementedError, \        "Child of Abstract Class Seq must specify order"    if not isinstance(self._order, tuple):      raise ValidityError, "Seq must have tuple as order"    self.validate()    self._tag = self.__class__.__name__

一旦應用程式程式員試圖建立 chapter 執行個體，執行個體化代碼就檢查是否用所要求的 ._order 類屬性聲明了 chapter ，並檢查該屬性是否為所需的元組對象。方法 .validate() 要做進一步的檢查，以確保初始化執行個體所用的對象屬於 ._order 中指定的相應類。

何時聲明

宣告式程式設計樣式在聲明約束方面 幾乎一直比命令式或過程式樣式更直接。當然，並非所有的編程問題都是關於約束的 － 或者說至少這並非總是自然定律。但是如果基於規則的系統（比如文法和推理系統）可以進行聲明性描述，那麼它們的問題就比較容易處理了。是否符合文法的命令式驗證很快就會變成非常複雜難懂的所謂“意大利麵條式代碼”（spaghetti code），而且很難調試。模式和規則的聲明仍然可以更簡單。

當然，起碼在 Python 中，聲明規則的驗證和增強總是會歸結為過程式檢查。但是把這種過程式檢查放在進行了良好測試的庫代碼中比較合適。單獨的應用程式應該依靠由像 Spark 或 PLY 或 gnosis.xml.validity 這樣的庫所提供的更簡單的聲明性介面。其它像 xmlproc 、 SimpleParse 或 ft.4xslt 這樣的庫，儘管不是 用 Python進行聲明的（Python 當然適用於它們的領域），也能使用聲明性樣式。

