大多數(shù)程序員考慮編程時，他們都要設(shè)想用于編寫應(yīng)用程序的 命令式樣式和技術(shù)。最受歡迎的通用編程語言（包括 Python 和其它面向?qū)ο蟮恼Z言）在樣式上絕大多數(shù)都是命令式的。另一方面，也有許多編程語言是 聲明性樣式，包括函數(shù)語言和邏輯語言，還包括通用語言和專用語言。

讓我們列出幾個屬于各個種類的語言。許多讀者已經(jīng)使用過這些工具中的許多工具，但不見得考慮過它們之間的種類差別。Python、C、C++、Java、Perl、Ruby、Smalltalk、Fortran、Basic 和 xBase 都是簡單的命令式編程語言。其中，一些是面向?qū)ο蟮?，但那只是組織代碼和數(shù)據(jù)的問題，而非基本編程樣式的問題。使用這些語言，您 命令程序執(zhí)行指令序列：把某些數(shù)據(jù) 放入（put）變量中；從變量中 獲?。╢etch）數(shù)據(jù)； 循環(huán)（loop）一個指令塊 直到（until）滿足了某些條件； 如果（if）某個命題為 true，那么就進(jìn)行某些操作。所有這些語言的一個妙處在于：便于用日常生活中熟悉的比喻來考慮它們。日常生活都是由做事、選擇、再做另一件事所組成的，期間或許會使用一些工具?？梢院唵蔚貙⑦\(yùn)行程序的計(jì)算機(jī)想象成廚師、瓦匠或汽車司機(jī)。

諸如 Prolog、Mercury、SQL、XSLT 這樣的語言、EBNF 語法和各種格式的真正配置文件，都 聲明某事是這種情況，或者應(yīng)用了某些約束。函數(shù)語言（比如 Haskell、ML、Dylan、Ocaml 和 Scheme）與此相似，但是它們更加強(qiáng)調(diào)陳述編程對象（遞歸、列表，等等）之間的內(nèi)部（函數(shù)）關(guān)系。我們的日常生活（至少在敘事質(zhì)量方面）沒有提供對這些語言的編程構(gòu)造的直接模擬。然而，對于那些可以用這些語言進(jìn)行描述的問題來說，聲明性描述 遠(yuǎn)遠(yuǎn)比命令式解決方案來得簡明且不易出錯。例如，請研究下面這個線性方程組：
清單 1. 線性方程式系統(tǒng)樣本

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

這是個相當(dāng)漂亮的說明對象（x、y 和 z）之間幾個關(guān)系的簡單表達(dá)式。在現(xiàn)實(shí)生活中您可能會用不同的方式求出這些答案，但是實(shí)際上用筆和紙“求解 x”很煩，而且容易出錯。從調(diào)試角度來講，用 Python 編寫求解步驟或許會更糟糕。

Prolog 是與邏輯或數(shù)學(xué)關(guān)系密切的語言。使用這種語言，您只要編寫您知道是正確的語句，然后讓應(yīng)用程序?yàn)槟贸鼋Y(jié)果。語句不是按照特定的順序構(gòu)成的（和線性方程式一樣，沒有順序），而且您（程序員或用戶）并不知道得出的結(jié)果都采用了哪些步驟。例如：
清單 2. family.pro Prolog 樣本

/* Adapted from sample at:
<http://www.engin.umd.umich.edu/CIS/course.des/cis479/prolog/>
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（擴(kuò)展巴科斯范式，Extended Backus-Naur Form）語法聲明并不完全一樣，但是實(shí)質(zhì)相似。您可以編寫一些下面這樣的聲明：
清單 3. EBNF 樣本

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

如果您遇到一個單詞而想要表述其看上去 可能會是什么，而實(shí)際上又不想給出如何識別它的序列指令，上面便是個簡練的方法。正則表達(dá)式與此相似（并且事實(shí)上它能夠滿足這種特定語法產(chǎn)品的需要）。

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

<!ELEMENT dissertation (chapter+)>
<!ELEMENT chapter (title, paragraph+)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT paragraph (#PCDATA | figure)+>
<!ELEMENT figure EMPTY>

和其它示例一樣，DTD 語言不包含任何有關(guān)如何識別或創(chuàng)建有效 XML 文檔的指令。它只描述了如果文檔存在，那它會是怎么樣的。聲明性語言采用虛擬語氣。
Python 作為解釋器 vs Python 作為環(huán)境

Python 庫可以通過兩種截然不同的方式中的一種來利用聲明性語言?；蛟S更為常用的技術(shù)是將非 Python 聲明性語言作為數(shù)據(jù)來解析和處理。應(yīng)用程序或庫可以讀入外部來源（或者是內(nèi)部定義的但只用作“blob”的字符串），然后指出一組要執(zhí)行的命令式步驟，這些步驟在某種形式上與那些外部聲明是一致的。本質(zhì)上，這些類型的庫是“數(shù)據(jù)驅(qū)動的”系統(tǒng)；聲明性語言和 Python 應(yīng)用程序執(zhí)行或利用其聲明的操作之間有著概念和范疇差別。事實(shí)上，相當(dāng)普遍的一點(diǎn)是，處理那些相同聲明的庫也被用來實(shí)現(xiàn)其它編程語言。

上面給出的所有示例都屬于第一種技術(shù)。庫 PyLog 是 Prolog 系統(tǒng)的 Python 實(shí)現(xiàn)。它讀取像樣本那樣的 Prolog 數(shù)據(jù)文件，然后創(chuàng)建 Python 對象來對 Prolog 聲明 建模。EBNF 樣本使用專門變體 SimpleParse ，這是一個 Python 庫，它將這些聲明轉(zhuǎn)換成可以被 mx.TextTools 所使用的狀態(tài)表。 mx.TextTools 自身是 Python 的擴(kuò)展庫，它使用底層 C 引擎來運(yùn)行存儲在 Python 數(shù)據(jù)結(jié)構(gòu)中的代碼，但與 Python 本質(zhì)上幾乎沒什么關(guān)系。對于這些任務(wù)而言，Python 是極佳的 粘合劑，但是粘合在一起的語言與 Python 差別很大。而且，大多數(shù) Prolog 實(shí)現(xiàn)都不是用 Python 編寫的，這和大多數(shù) EBNF 解析器一樣。

DTD 類似于其它示例。如果您使用象 xmlproc 這樣的驗(yàn)證解析器，您可以利用 DTD 來驗(yàn)證 XML 文檔的方言。但是 DTD 的語言并不是 Python 式的， xmlproc 只將它用作需要解析的數(shù)據(jù)。而且，已經(jīng)用許多編程語言編寫過 XML 驗(yàn)證解析器。XSLT 轉(zhuǎn)換與此相似，也不是特定于 Python 的，而且像 ft.4xslt 這樣的模塊只將 Python 用作“粘合劑”。

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

自省的魔力

解析器 Spark 和 PLY 讓用戶 用 Python 來聲明 Python 值，然后使用某些魔法來讓 Python 運(yùn)行時環(huán)境進(jìn)行解析配置。例如，讓我們研究一下與前面 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 t
import lex
lex.lex()
lex.input(sometext)
while 1:
  t = lex.token()
  if not t: break

我已經(jīng)在我即將出版的書籍 Text Processing in Python 中編寫了有關(guān) PLY 的內(nèi)容，并且在本專欄文章中編寫了有關(guān) Spark 的內(nèi)容（請參閱 參考資料以獲取相應(yīng)鏈接）。不必深入了解庫的詳細(xì)信息，這里您應(yīng)當(dāng)注意的是：正是 Python 綁定本身配置了解析（在這個示例中實(shí)際是詞法分析/標(biāo)記化）。 PLY 模塊在 Python 環(huán)境中運(yùn)行以作用于這些模式聲明，因此就正好非常了解該環(huán)境。

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

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()

這種樣式的聲明性并不差，而且可以假設(shè) basic_lex 模塊包含類似下面這樣的簡單內(nèi)容：
清單 7. basic_lex.py

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

這會產(chǎn)生：

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

PLY 設(shè)法使用堆棧幀信息插入了導(dǎo)入模塊的名稱空間。例如：
清單 8. magic_lex.py

import sys
try: raise RuntimeError
except RuntimeError:
  e,b,t = sys.exc_info()
  caller_dict = t.tb_frame.f_back.f_globals
def lex():
  for t in caller_dict['tokens']:
    print t, '=', caller_dict['t_'+t]

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

實(shí)際的 PLY 模塊中要比這更神奇。我們看到用模式 t_TOKEN 命名的標(biāo)記實(shí)際上可以是包含了正則表達(dá)式的字符串，或是包含了正則表達(dá)式文檔字符串和操作代碼的函數(shù)。某些類型檢查允許以下多態(tài)行為：
清單 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 模塊用這些已聲明的模式可以做更有趣的事，但是這些示例演示了其中所涉及的一些技術(shù)。

繼承的魔力

讓支持庫到處插入并操作應(yīng)用程序的名稱空間，這會啟用精妙的聲明性樣式。但通常，將繼承結(jié)構(gòu)和自省一起使用會使靈活性更佳。

模塊 gnosis.xml.validity 是用來創(chuàng)建直接映射到 DTD 產(chǎn)品的類的框架。任何 gnosis.xml.validity 類 只能用符合 XML 方言有效性約束的參數(shù)進(jìn)行實(shí)例化。實(shí)際上，這并不十分正確；當(dāng)只存在一種明確的方式可將參數(shù)“提升”成正確類型時，模塊也可從更簡單的參數(shù)中推斷出正確類型。

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

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

您可以使用以下命令從這些聲明中創(chuàng)建出實(shí)例：

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

請注意這些類和前面的 DTD 非常匹配。映射基本上是一一對應(yīng)的；除了有必要對嵌套標(biāo)記的量化和交替使用中介體之外（中介體名稱用前導(dǎo)下劃線標(biāo)出來）。

還要注意的是，這些類雖然是用標(biāo)準(zhǔn) Python 語法創(chuàng)建的，但它們也有不同尋常（且更簡練）之處：它們沒有方法或?qū)嵗龜?shù)據(jù)。單獨(dú)定義類，以便從某框架繼承類，而該框架受到單一的類屬性限制。例如， <chapter> 是其它標(biāo)記序列，即 <title> 后面跟著一個或多個 <paragraph> 標(biāo)記。但是為確保在實(shí)例中遵守約束，我們所需做的就是用這種簡單的方式來 聲明chapter 類。

編寫像 gnosis.xml.validity.Seq 這樣的父類程序所涉及的主要“技巧”，就是在初始化期間研究 實(shí)例的 .__class__ 屬性。類 chapter 自身并不進(jìn)行初始化，因此調(diào)用其父類的 __init__() 方法。但是傳遞給父類 __init__() 的 self 是 chapter 的實(shí)例，而且 self 知道 chapter。為了舉例說明這一點(diǎn)，下面列出了部分 gnosis.xml.validity.Seq 實(shí)現(xiàn)：
清單 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__

一旦應(yīng)用程序程序員試圖創(chuàng)建 chapter 實(shí)例，實(shí)例化代碼就檢查是否用所要求的 ._order 類屬性聲明了 chapter ，并檢查該屬性是否為所需的元組對象。方法 .validate() 要做進(jìn)一步的檢查，以確保初始化實(shí)例所用的對象屬于 ._order 中指定的相應(yīng)類。

何時聲明

聲明性編程樣式在聲明約束方面 幾乎一直比命令式或過程式樣式更直接。當(dāng)然，并非所有的編程問題都是關(guān)于約束的 － 或者說至少這并非總是自然定律。但是如果基于規(guī)則的系統(tǒng)（比如語法和推理系統(tǒng)）可以進(jìn)行聲明性描述，那么它們的問題就比較容易處理了。是否符合語法的命令式驗(yàn)證很快就會變成非常復(fù)雜難懂的所謂“意大利面條式代碼”（spaghetti code），而且很難調(diào)試。模式和規(guī)則的聲明仍然可以更簡單。

當(dāng)然，起碼在 Python 中，聲明規(guī)則的驗(yàn)證和增強(qiáng)總是會歸結(jié)為過程式檢查。但是把這種過程式檢查放在進(jìn)行了良好測試的庫代碼中比較合適。單獨(dú)的應(yīng)用程序應(yīng)該依靠由像 Spark 或 PLY 或 gnosis.xml.validity 這樣的庫所提供的更簡單的聲明性接口。其它像 xmlproc 、 SimpleParse 或 ft.4xslt 這樣的庫，盡管不是 用 Python進(jìn)行聲明的（Python 當(dāng)然適用于它們的領(lǐng)域），也能使用聲明性樣式。

最新評論