Lisp的本質(The Nature of Lisp)
作者 Slava Akhmechet
譯者 Alec Jang
出處: http://www.defmacro.org/ramblings/lisp.html
簡介
最初在web的某些角落偶然看到有人贊美Lisp時, 我那時已經是一個頗有經驗的程序員。
在我的履歷上, 掌握的語言范圍相當廣泛, 象C++, Java, C#主流語言等等都不在話下,
我覺得我差不多知道所有的有關編程語言的事情。對待編程語言的問題上, 我覺得自己不
太會遇到什么大問題。其實我大錯特錯了。
我試著學了一下Lisp, 結果馬上就撞了墻。我被那些范例代碼嚇壞了。我想很多初次接觸
Lisp語言的人, 一定也有過類似的感受。Lisp的語法太次了。一個語言的發明人, 居然不
肯用心弄出一套漂亮的語法, 那誰還會愿意學它。反正, 我是確確實實被那些難看的無數
的括號搞蒙了。
回過神來之后, 我和Lisp社區的那伙人交談, 訴說我的沮喪心情。結果, 立馬就有一大套
理論砸過來, 這套理論在Lisp社區處處可見, 幾成慣例。比如說: Lisp的括號只是表面現
象; Lisp的代碼和數據的表達方式沒有差別, 而且比XML語法高明許多, 所以有無窮的好
處; Lisp有強大無比的元語言能力, 程序員可以寫出自我維護的代碼; Lisp可以創造出針
對特定應用的語言子集; Lisp的運行時和編譯時沒有明確的分界; 等等, 等等, 等等。這
么長的贊美詞雖然看起來相當動人, 不過對我毫無意義。沒人能給我演示這些東西是如何
應用的, 因為這些東西一般來說只有在大型系統才會用到。我爭辯說, 這些東西傳統語言
一樣辦得到。在和別人爭論了數個小時之后, 我最終還是放棄了學Lisp的念頭。為什么要
花費幾個月的時間學習語法這么難看的語言呢? 這種語言的概念這么晦澀, 又沒什么好懂
的例子。也許這語言不是該我這樣的人學的。
幾個月來, 我承受著這些Lisp辯護士對我心靈的重壓。我一度陷入了困惑。我認識一些絕
頂聰明的人, 我對他們相當尊敬, 我看到他們對Lisp的贊美達到了宗教般的高度。這就是
說, Lisp中一定有某種神秘的東西存在, 我不能忍受自己對此的無知, 好奇心和求知欲最
終不可遏制。我于是咬緊牙關埋頭學習Lisp, 經過幾個月的時間費勁心力的練習, 終于,
我看到了那無窮無盡的泉水的源頭。在經過脫胎換骨的磨練之后, 在經過七重地獄的煎熬
之后, 終于, 我明白了。
頓悟在突然之間來臨。曾經許多次, 我聽到別人引用雷蒙德(譯者注: 論文<<大教堂和市
集>>的作者, 著名的黑客社區理論家)的話: "Lisp語言值得學習。當你學會Lisp之后, 你
會擁有深刻的體驗。就算你平常并不用Lisp編程, 它也會使你成為更加優秀的程序員"。
過去, 我根本不懂這些話的含義, 我也不相信這是真的。可是現在我懂得了。這些話蘊含
的真理遠遠超過我過去的想像。我內心體會到一種神圣的情感, 一瞬間的頓悟, 幾乎使我
對電腦科學的觀念發生了根本的改變。
頓悟的那一刻, 我成了Lisp的崇拜者。我體驗到了宗教大師的感受: 一定要把我的知識傳
布開來, 至少要讓10個迷失的靈魂得到拯救。按照通常的辦法, 我把這些道理(就是剛開
始別人砸過來的那一套, 不過現在我明白了真實的含義)告訴旁人。結果太令人失望了,
只有少數幾個人在我堅持之下, 發生了一點興趣, 但是僅僅看了幾眼Lisp代碼, 他們就退
卻了。照這樣的辦法, 也許費數年功夫能造就了幾個Lisp迷, 但我覺得這樣的結果太差強
人意了, 我得想一套有更好的辦法。
我深入地思考了這個問題。是不是Lisp有什么很艱深的東西, 令得那么多老練的程序員都
不能領會? 不是, 沒有任何絕對艱深的東西。因為我能弄懂, 我相信其他人也一定能。那
么問題出在那里? 后來我終于找到了答案。我的結論就是, 凡是教人學高級概念, 一定要
從他已經懂得的東西開始。如果學習過程很有趣, 學習的內容表達得很恰當, 新概念就會
變得相當直觀。這就是我的答案。所謂元編程, 所謂數據和代碼形式合一, 所謂自修改代
碼, 所謂特定應用的子語言, 所有這些概念根本就是同族概念, 彼此互為解釋, 肯定越講
越不明白。還是從實際的例子出發最有用。
我把我的想法說給Lisp程序員聽, 遭到了他們的反對。"這些東西本身當然不可能用熟悉
的知識來解釋, 這些概念完全與眾不同, 你不可能在別人已有的經驗里找到類似的東西",
可是我認為這些都是遁詞。他們又反問我, "你自己為啥不試一下?" 好吧, 我來試一下。
這篇文章就是我嘗試的結果。我要用熟悉的直觀的方法來解釋Lisp, 我希望有勇氣的人讀
完它, 拿杯飲料, 深呼吸一下, 準備被搞得暈頭轉向。來吧, 愿你獲得大能。
重新審視XML
千里之行始于足下。讓我們的第一步從XML開始。可是XML已經說得更多的了, 還能有什么
新意思可說呢? 有的。XML自身雖然談談不上有趣, 但是XML和Lisp的關系卻相當有趣。
XML和Lisp的概念有著驚人的相似之處。XML是我們通向理解Lisp的橋梁。好吧, 我們且把
XML當作活馬醫。讓我們拿好手杖, 對XML的無人涉及的荒原地帶作一番探險。我們要從一
個全新的視角來考察這個題目。
表面上看, XML是一種標準化語法, 它以適合人閱讀的格式來表達任意的層次化數據
(hirearchical data)。象任務表(to-do list), 網頁, 病歷, 汽車保險單, 配置文件等
等, 都是XML用武的地方。比如我們拿任務表做例子:
<todo name="housework">
<item priority="high">Clean the house.</item>
<item priority="medium">Wash the dishes.</item>
<item priority="medium">Buy more soap.</item>
</todo>
解析這段數據時會發生什么情況? 解析之后的數據在內存中怎樣表示? 顯然, 用樹來表示
這種層次化數據是很恰當的。說到底, XML這種比較容易閱讀的數據格式, 就是樹型結構
數據經過序列化之后的結果。任何可以用樹來表示的數據, 同樣可以用XML來表示, 反之
亦然。希望你能懂得這一點, 這對下面的內容極其重要。
再進一步。還有什么類型的數據也常用樹來表示? 無疑列表(list)也是一種。上過編譯課
吧? 還模模糊糊記得一點吧? 源代碼在解析之后也是用樹結構來存放的, 任何編譯程序都
會把源代碼解析成一棵抽象語法樹, 這樣的表示法很恰當, 因為源代碼就是層次結構的:
函數包含參數和代碼塊, 代碼快包含表達式和語句, 語句包含變量和運算符等等。
我們已經知道, 任何樹結構都可以輕而易舉的寫成XML, 而任何代碼都會解析成樹, 因此,
任何代碼都可以轉換成XML, 對不對? 我舉個例子, 請看下面的函數:
int add(int arg1, int arg2)
{
return arg1+arg2;
}
能把這個函數變成對等的XML格式嗎? 當然可以。我們可以用很多種方式做到, 下面是其
中的一種, 十分簡單:
<define-function return-type="int" name="add">
<arguments>
<argument type="int">arg1</argument>
<argument type="int">arg2</argument>
</arguments>
<body>
<return>
<add value1="arg1" value2="arg2" />
</return>
</body>
</define>
這個例子非常簡單, 用哪種語言來做都不會有太大問題。我們可以把任何程序碼轉成XML,
也可以把XML轉回到原來的程序碼。我們可以寫一個轉換器, 把Java代碼轉成XML, 另一個
轉換器把XML轉回到Java。一樣的道理, 這種手段也可以用來對付C++(這樣做跟發瘋差不
多么。可是的確有人在做, 看看GCC-XML(http://www.gccxml.org)就知道了)。進一步說,
凡是有相同語言特性而語法不同的語言, 都可以把XML當作中介來互相轉換代碼。實際上
幾乎所有的主流語言都在一定程度上滿足這個條件。我們可以把XML作為一種中間表示法,
在兩種語言之間互相譯碼。比方說, 我們可以用Java2XML把Java代碼轉換成XML, 然后用
XML2CPP再把XML轉換成C++代碼, 運氣好的話, 就是說, 如果我們小心避免使用那些C++不
具備的Java特性的話, 我們可以得到完好的C++程序。這辦法怎么樣, 漂亮吧?
這一切充分說明, 我們可以把XML作為源代碼的通用存儲方式, 其實我們能夠產生一整套
使用統一語法的程序語言, 也能寫出轉換器, 把已有代碼轉換成XML格式。如果真的采納
這種辦法, 各種語言的編譯器就用不著自己寫語法解析了, 它們可以直接用XML的語法解
析來直接生成抽象語法樹。
說到這里你該問了, 我們研究了這半天XML, 這和Lisp有什么關系呢? 畢竟XML出來之時,
Lisp早已經問世三十年了。這里我可以保證, 你馬上就會明白。不過在繼續解釋之前, 我
們先做一個小小的思維練習。看一下上面這個XML版本的add函數例子, 你怎樣給它分類,
是代碼還是數據? 不用太多考慮都能明白, 把它分到哪一類都講得通。它是XML, 它是標
準格式的數據。我們也知道, 它可以通過內存中的樹結構來生成(GCC-XML做的就是這個事
情)。它保存在不可執行的文件中。我們可以把它解析成樹節點, 然后做任意的轉換。顯
而易見, 它是數據。不過且慢, 雖然它語法有點陌生, 可它又確確實實是一個add函數,
對吧? 一旦經過解析, 它就可以拿給編譯器編譯執行。我們可以輕而易舉寫出這個XML
代碼解釋器, 并且直接運行它。或者我們也可以把它譯成Java或C++代碼, 然后再編譯運
行。所以說, 它也是代碼。
我們說到那里了? 不錯, 我們已經發現了一個有趣的關鍵之點。過去被認為很難解的概念
已經非常直觀非常簡單的顯現出來。代碼也是數據, 并且從來都是如此。這聽起來瘋瘋癲
癲的, 實際上卻是必然之事。我許諾過會以一種全新的方式來解釋Lisp, 我要重申我的許
諾。但是我們此刻還沒有到預定的地方, 所以還是先繼續上邊的討論。
剛才我說過, 我們可以非常簡單地實現XML版的add函數解釋器, 這聽起來好像不過是說說
而已。誰真的會動手做一下呢? 未必有多少人會認真對待這件事。隨便說說, 并不打算真
的去做, 這樣的事情你在生活中恐怕也遇到吧。你明白我這樣說的意思吧, 我說的有沒有
打動你? 有哇, 那好, 我們繼續。
重新審視Ant
我們現在已經來到了月亮背光的那一面, 先別忙著離開。再探索一下, 看看我們還能發現
什么東西。閉上眼睛, 想一想2000年冬天的那個雨夜, 一個名叫James Duncan Davidson
的杰出的程序員正在研究Tomcat的servlet容器。那時, 他正小心地保存好剛修改過的文
件, 然后執行make。結果冒出了一大堆錯誤, 顯然有什么東西搞錯了。經過仔細檢查, 他
想, 難道是因為tab前面加了個空格而導致命令不能執行嗎? 確實如此。老是這樣, 他真
的受夠了。烏云背后的月亮給了他啟示, 他創建了一個新的Java項目, 然后寫了一個簡單
但是十分有用的工具, 這個工具巧妙地利用了Java屬性文件中的信息來構造工程, 現在
James可以寫makefile的替代品, 它能起到相同的作用, 而形式更加優美, 也不用擔心有
makefile那樣可恨的空格問題。這個工具能夠自動解釋屬性文件, 然后采取正確的動作來
編譯工程。真是簡單而優美。
(作者注: 我不認識James, James也不認識我, 這個故事是根據網上關于Ant歷史的帖子
虛構的)
使用Ant構造Tomcat之后幾個月, 他越來越感到Java的屬性文件不足以表達復雜的構造指
令。文件需要檢出, 拷貝, 編譯, 發到另外一臺機器, 進行單元測試。要是出錯, 就發郵
件給相關人員, 要是成功, 就繼續在盡可能高層的卷(volumn)上執行構造。追蹤到最后,
卷要回復到最初的水平上。確實, Java的屬性文件不夠用了, James需要更有彈性的解決
方案。他不想自己寫解析器(因為他更希望有一個具有工業標準的方案)。XML看起來是個
不錯的選擇。他花了幾天工夫把Ant移植到XML，于是，一件偉大的工具誕生了。
Ant是怎樣工作的？原理非常簡單。Ant把包含有構造命令的XML文件(算代碼還是算數據,
你自己想吧)，交給一個Java程序來解析每一個元素，實際情況比我說的還要簡單得多。
一個簡單的XML指令會導致具有相同名字的Java類裝入，并執行其代碼。
<copy todir="../new/dir">
<fileset dir="src_dir" />
</copy>
這段文字的含義是把源目錄復制到目標目錄，Ant會找到一個"copy"任務(實際上就是一個
Java類), 通過調用Java的方法來設置適當參數(todir和fileset)，然后執行這個任務。
Ant帶有一組核心類, 可以由用戶任意擴展, 只要遵守若干約定就可以。Ant找到這些類,
每當遇到XML元素有同樣的名字, 就執行相應的代碼。過程非常簡單。Ant做到了我們前面
所說的東西: 它是一個語言解釋器, 以XML作為語法, 把XML元素轉譯為適當的Java指令。
我們可以寫一個"add"任務, 然后, 當發現XML中有add描述的時候, 就執行這個add任務。
由于Ant是非常流行的項目, 前面展示的策略就顯得更為明智。畢竟, 這個工具每天差不
多有幾千家公司在使用。
到目前為之, 我還沒有說Ant在解析XML時所遇到困難。你也不用麻煩去它的網站上去找答
案了, 不會找到有價值的東西。至少對我們這個論題來說是如此。我們還是繼續下一步討
論吧。我們答案就在那里。
為什么是XML
有時候正確的決策并非完全出于深思熟慮。我不知道James選擇XML是否出于深思熟慮。也
許僅僅是個下意識的決定。至少從James在Ant網站上發表的文章看起來, 他所說的理由完
全是似是而非。他的主要理由是移植性和擴展性, 在Ant案例上, 我看不出這兩條有什么
幫助。使用XML而不是Java代碼, 到底有什么好處? 為什么不寫一組Java類, 提供api來滿
足基本任務(拷貝目錄, 編譯等等), 然后在Java里直接調用這些代碼? 這樣做仍然可以保
證移植性, 擴展性也是毫無疑問的。而且語法也更為熟悉, 看著順眼。那為什么要用 XML
呢? 有什么更好的理由嗎?
有的。雖然我不確定James是否確實意識到了。在語義的可構造性方面, XML的彈性是Java
望塵莫及的。我不想用高深莫測的名詞來嚇唬你, 其中的道理相當簡單, 解釋起來并不費
很多功夫。好, 做好預備動作, 我們馬上就要朝向頓悟的時刻做奮力一躍。
上面的那個copy的例子, 用Java代碼怎樣實現呢? 我們可以這樣做:
CopyTask copy = new CopyTask();
Fileset fileset = new Fileset();
fileset.setDir("src_dir");
copy.setToDir("../new/dir");
copy.setFileset(fileset);
copy.excute();
這個代碼看起來和XML的那個很相似, 只是稍微長一點。差別在那里? 差別在于XML構造了
一個特殊的copy動詞, 如果我們硬要用Java來寫的話, 應該是這個樣子:
copy("../new/dir");
{
fileset("src_dir");
}
看到差別了嗎? 以上代碼(如果可以在Java中用的化), 是一個特殊的copy算符, 有點像
for循環或者Java5中的foreach循環。如果我們有一個轉換器, 可以把XML轉換到Java, 大
概就會得到上面這段事實上不可以執行的代碼。因為Java的技術規范是定死的, 我們沒有
辦法在程序里改變它。我們可以增加包, 增加類, 增加方法, 但是我們沒辦法增加算符,
而對于XML, 我們顯然可以任由自己增加這樣的東西。對于XML的語法樹來說, 只要原意,
我們可以任意增加任何元素, 因此等于我們可以任意增加算符。如果你還不太明白的話,
看下面這個例子, 加入我們要給Java引入一個unless算符:
unless(someObject.canFly())
{
someObject.transportByGround():
}
在上面的兩個例子中, 我們打算給Java語法擴展兩個算符, 成組拷貝文件算符和條件算符
unless, 我們要想做到這一點, 就必須修改Java編譯器能夠接受的抽象語法樹, 顯然我們
無法用Java標準的功能來實現它。但是在XML中我們可以輕而易舉地做到。我們的解析器
根據 XML元素, 生成抽象語法樹, 由此生成算符, 所以, 我們可以任意引入任何算符。
對于復雜的算符來說, 這樣做的好處顯而易見。比如, 用特定的算符來做檢出源碼, 編譯
文件, 單元測試, 發送郵件等任務, 想想看有多么美妙。對于特定的題目, 比如說構造軟
件項目, 這些算符的使用可以大幅減低少代碼的數量。增加代碼的清晰程度和可重用性。
解釋性的XML可以很容易的達到這個目標。XML是存儲層次化數據的簡單數據文件, 而在
Java中, 由于層次結構是定死的(你很快就會看到, Lisp的情況與此截然不同), 我們就沒
法達到上述目標。也許這正是Ant的成功之處呢。
你可以注意一下最近Java和C#的變化(尤其是C#3.0的技術規范), C#把常用的功能抽象出
來, 作為算符增加到C#中。C#新增加的query算符就是一個例子。它用的還是傳統的作法:
C#的設計者修改抽象語法樹, 然后增加對應的實現。如果程序員自己也能修改抽象語法樹
該有多好! 那樣我們就可以構造用于特定問題的子語言(比如說就像Ant這種用于構造項目
的語言), 你能想到別的例子嗎? 再思考一下這個概念。不過也不必思考太甚, 我們待會
還會回到這個題目。那時候就會更加清晰。
離Lisp越來越近
我們先把算符的事情放一放, 考慮一下Ant設計局限之外的東西。我早先說過, Ant可以通
過寫Java類來擴展。Ant解析器會根據名字來匹配XML元素和Java類, 一旦找到匹配, 就執
行相應任務。為什么不用Ant自己來擴展Ant呢? 畢竟核心任務要包含很多傳統語言的結構
(例如"if"), 如果Ant自身就能提供構造任務的能力(而不是依賴java類), 我們就可以得
到更高的移植性。我們將會依賴一組核心任務(如果你原意, 也不妨把它稱作標準庫), 而
不用管有沒有Java 環境了。這組核心任務可以用任何方式來實現, 而其他任務建筑在這
組核心任務之上, 那樣的話, Ant就會成為通用的, 可擴展的, 基于XML的編程語言。考慮
下面這種代碼的可能性:
<task name="Test">
<echo message="Hello World" />
</task>
<Test />
如果XML支持"task"的創建, 上面這段代碼就會輸出"Hello World!". 實際上, 我們可以
用Java寫個"task"任務, 然后用Ant-XML來擴展它。Ant可以在簡單原語的基礎上寫出更復
雜的原語, 就像其他編程語言常用的作法一樣。這也就是我們一開始提到的基于XML的編
程語言。這樣做用處不大(你知道為甚么嗎?), 但是真的很酷。
再看一回我們剛才說的Task任務。祝賀你呀, 你在看Lisp代碼!!! 我說什么? 一點都不像
Lisp嗎? 沒關系, 我們再給它收拾一下。
比XML更好
前面一節說過, Ant自我擴展沒什么大用, 原因在于XML很煩瑣。對于數據來說, 這個問題
還不太大, 但如果代碼很煩瑣的話, 光是打字上的麻煩就足以抵消它的好處。你寫過Ant
的腳本嗎? 我寫過, 當腳本達到一定復雜度的時候, XML非常讓人厭煩。想想看吧, 為了
寫結束標簽, 每個詞都得打兩遍, 不發瘋算好的!
為了解決這個問題, 我們應當簡化寫法。須知, XML僅僅是一種表達層次化數據的方式。
我們并不是一定要使用尖括號才能得到樹的序列化結果。我們完全可以采用其他的格式。
其中的一種(剛好就是Lisp所采用的)格式, 叫做s表達式。s表達式要做的和XML一樣, 但
它的好處是寫法更簡單, 簡單的寫法更適合代碼輸入。后面我會詳細講s表達式。這之前
我要清理一下XML的東西。考慮一下關于拷貝文件的例子:
<copy toDir="../new/dir">
<fileset dir="src_dir">
</copy>
想想看在內存里面, 這段代碼的解析樹在內存會是什么樣子? 會有一個"copy"節點, 其下
有一個 "fileset"節點, 但是屬性在哪里呢? 它怎樣表達呢? 如果你以前用過XML, 并且
弄不清楚該用元素還是該用屬性, 你不用感到孤單, 別人一樣糊涂著呢。沒人真的搞得清
楚。這個選擇與其說是基于技術的理由, 還不如說是閉著眼瞎摸。從概念上來講, 屬性也
是一種元素, 任何屬性能做的, 元素一樣做得到。XML引入屬性的理由, 其實就是為了讓
XML寫法不那么冗長。比如我們看個例子:
<copy>
<toDir>../new/dir</toDir>
<fileset>
<dir>src_dir</dir>
</fileset>
</copy>
兩下比較, 內容的信息量完全一樣, 用屬性可以減少打字數量。如果XML沒有屬性的話,
光是打字就夠把人搞瘋掉。
說完了屬性的問題, 我們再來看一看s表達式。之所以繞這么個彎, 是因為s表達式沒有屬
性的概念。因為s表達式非常簡練, 根本沒有必要引入屬性。我們在把XML轉換成s表達式
的時候, 心里應該記住這一點。看個例子, 上面的代碼譯成s表達式是這樣的:
(copy
(todir "../new/dir")
(fileset (dir "src_dir")))
仔細看看這個例子, 差別在哪里? 尖括號改成了圓括號, 每個元素原來是有一對括號標記
包圍的, 現在取消了后一個(就是帶斜杠的那個)括號標記。表示元素的結束只需要一個")"
就可以了。不錯, 差別就是這些。這兩種表達方式的轉換, 非常自然, 也非常簡單。s表
達式打起字來, 也省事得多。第一次看s表達式(Lisp)時, 括號很煩人是吧? 現在我們明
白了背后的道理, 一下子就變得容易多了。至少, 比XML要好的多。用s表達式寫代碼, 不
單是實用, 而且也很讓人愉快。s表達式具有XML的一切好處, 這些好處是我們剛剛探討過
的。現在我們看看更加Lisp風格的task例子:
(task (name "Test")
(echo (message "Hellow World!")))
(Test)
用Lisp的行話來講, s表達式稱為表(list)。對于上面的例子, 如果我們寫的時候不加換
行, 用逗號來代替空格, 那么這個表達式看起來就非常像一個元素列表, 其中又嵌套著其
他標記。
(task, (name, "test"), (echo, (message, "Hello World!")))
XML自然也可以用這樣的風格來寫。當然上面這句并不是一般意義上的元素表。它實際上
是一個樹。這和XML的作用是一樣的。稱它為列表, 希望你不會感到迷惑, 因為嵌套表和
樹實際上是一碼事。Lisp的字面意思就是表處理(list processing), 其實也可以稱為樹
處理, 這和處理XML節點沒有什么不同。
經受這一番折磨以后, 現在我們終于相當接近Lisp了, Lisp的括號的神秘本質(就像許多
Lisp狂熱分子認為的)逐漸顯現出來。現在我們繼續研究其他內容。
重新審視C語言的宏
到了這里, 對XML的討論你大概都聽累了, 我都講累了。我們先停一停, 把樹, s表達式,
Ant這些東西先放一放, 我們來說說C的預處理器。一定有人問了, 我們的話題和C有什么
關系? 我們已經知道了很多關于元編程的事情, 也探討過專門寫代碼的代碼。理解這問題
有一定難度, 因為相關討論文章所使用的編程語言, 都是你們不熟悉的。但是如果只論概
念的話, 就相對要簡單一些。我相信, 如果以C語言做例子來討論元編程, 理解起來一定
會容易得多。好, 我們接著看。
一個問題是, 為什么要用代碼來寫代碼呢? 在實際的編程中, 怎樣做到這一點呢? 到底元
編程是什么意思? 你大概已經聽說過這些問題的答案, 但是并不懂得其中緣由。為了揭示
背后的真理, 我們來看一下一個簡單的數據庫查詢問題。這種題目我們都做過。比方說,
直接在程序碼里到處寫SQL語句來修改表(table)里的數據, 寫多了就非常煩人。即便用
C#3.0的LINQ, 仍然不減其痛苦。寫一個完整的SQL查詢(盡管語法很優美)來修改某人的地
址, 或者查找某人的名字, 絕對是件令程序員倍感乏味的事情, 那么我們該怎樣來解決這
個問題? 答案就是: 使用數據訪問層。
概念挺簡單, 其要點是把數據訪問的內容(至少是那些比較瑣碎的部分)抽象出來, 用類來
映射數據庫的表, 然后用訪問對象屬性訪問器(accessor)的辦法來間接實現查詢。這樣就
極大地簡化了開發工作量。我們用訪問對象的方法(或者屬性賦值, 這要視你選用的語言
而定)來代替寫SQL查詢語句。凡是用過這種方法的人, 都知道這很節省時間。當然, 如果
你要親自寫這樣一個抽象層, 那可是要花非常多的時間的--你要寫一組類來映射表, 把屬
性訪問轉換為SQL查詢, 這個活相當耗費精力。用手工來做顯然是很不明智的。但是一旦
你有了方案和模板, 實際上就沒有多少東西需要思考的。你只需要按照同樣的模板一次又
一次重復編寫相似代碼就可以了。事實上很多人已經發現了更好的方法, 有一些工具可以
幫助你連接數據庫, 抓取數據庫結構定義(schema), 按照預定義的或者用戶定制的模板來
自動編寫代碼。
如果你用過這種工具, 你肯定會對它的神奇效果深為折服。往往只需要鼠標點擊數次, 就
可以連接到數據庫, 產生數據訪問源碼, 然后把文件加入到你的工程里面, 十幾分鐘的工
作, 按照往常手工方式來作的話, 也許需要數百個小時人工(man-hours)才能完成。可是,
如果你的數據庫結構定義后來改變了怎么辦? 那樣的話, 你只需把這個過程重復一遍就可
以了。甚至有一些工具能自動完成這項變動工作。你只要把它作為工程構造的一部分, 每
次編譯工程的時候, 數據庫部分也會自動地重新構造。這真的太棒了。你要做的事情基本
上減到了0。如果數據庫結構定義發生了改變, 并在編譯時自動更新了數據訪問層的代碼,
那么程序中任何使用過時的舊代碼的地方, 都會引發編譯錯誤。
數據訪問層是個很好的例子, 這樣的例子還有好多。從GUI樣板代碼, WEB代碼, COM和
CORBA存根, 以及MFC和ATL等等。在這些地方, 都是有好多相似代碼多次重復。既然這些
代碼有可能自動編寫, 而程序員時間又遠遠比CPU時間昂貴, 當然就產生了好多工具來自
動生成樣板代碼。這些工具的本質是什么呢? 它們實際上就是制造程序的程序。它們有一
個神秘的名字, 叫做元編程。所謂元編程的本義, 就是如此。
元編程本來可以用到無數多的地方, 但實際上使用的次數卻沒有那么多。歸根結底, 我們
心里還是在盤算, 假設重復代碼用拷貝粘貼的話, 大概要重復6,7次, 對于這樣的工作量,
值得專門建立一套生成工具嗎? 當然不值得。數據訪問層和COM存根往往需要重用數百次,
甚至上千次, 所以用工具生成是最好的辦法。而那些僅僅是重復幾次十幾次的代碼, 是沒
有必要專門做工具的。不必要的時候也去開發代碼生成工具, 那就顯然過度估計了代碼生
成的好處。當然, 如果創建這類工具足夠簡單的話, 還是應當盡量多用, 因為這樣做必然
會節省時間。現在來看一下有沒有合理的辦法來達到這個目的。
現在, C預處理器要派上用場了。我們都用過C/C++的預處理器, 我們用它執行簡單的編譯
指令, 來產生簡單的代碼變換(比方說, 設置調試代碼開關), 看一個例子:
#define triple(X) X+X+X
這一行的作用是什么? 這是一個簡單的預編譯指令, 它把程序中的triple(X)替換稱為
X+X+X。例如, 把所有的triple(5)都換成5+5+5, 然后再交給編譯器編譯。這就是一個簡
單的代碼生成的例子。要是C的預處理器再強大一點, 要是能夠允許連接數據庫, 要是能
多一些其他簡單的機制, 我們就可以在我們程序的內部開發自己的數據訪問層。下面這個
例子, 是一個假想的對C宏的擴展:
#get-db-schema("127.0.0.1")
#iterate-through-tables
#for-each-table
class #table-name
{
};
#end-for-each
我們連接數據庫結構定義, 遍歷數據表, 然后對每個表創建一個類, 只消幾行代碼就完成
了這個工作。這樣每次編譯工程的時候, 這些類都會根據數據庫的定義同步更新。顯而易
見, 我們不費吹灰之力就在程序內部建立了一個完整的數據訪問層, 根本用不著任何外部
工具。當然這種作法有一個缺點, 那就是我們得學習一套新的"編譯時語言", 另一個缺點
就是根本不存在這么一個高級版的C預處理器。需要做復雜代碼生成的時候, 這個語言(譯
者注: 這里指預處理指令, 即作者所說的"編譯時語言")本身也一定會變得相當復雜。它
必須支持足夠多的庫和語言結構。比如說我們想要生成的代碼要依賴某些ftp服務器上的
文件, 預處理器就得支持ftp訪問, 僅僅因為這個任務而不得不創造和學習一門新的語言,
真是有點讓人惡心(事實上已經存在著有此能力的語言, 這樣做就更顯荒謬)。我們不妨再
靈活一點, 為什么不直接用 C/C++自己作為自己的預處理語言呢? 這樣子的話, 我們可
以發揮語言的強大能力, 要學的新東西也只不過是幾個簡單的指示字 , 這些指示字用來
區別編譯時代碼和運行時代碼。
<%
cout<<"Enter a number: ";
cin>>n;
%>
for(int i=0;i< <% n %>;i++)
{
cout<<"hello"<<endl;
}
你明白了嗎? 在<%和%>標記之間的代碼是在編譯時運行的, 標記之外的其他代碼都是普通
代碼。編譯程序時, 系統會提示你輸入一個數, 這個數在后面的循環中會用到。而for循
環的代碼會被編譯。假定你在編譯時輸入5, for循環的代碼將會是:
for(int i=0;i<5; i++)
{
cout<<"hello"<<endl;
}
又簡單又有效率, 也不需要另外的預處理語言。我們可以在編譯時就充分發揮宿主語言(
此處是C/C++)的強大能力, 我們可以很容易地在編譯時連接數據庫, 建立數據訪問層, 就
像JSP或者ASP創建網頁那樣。我們也用不著專門的窗口工具來另外建立工程。我們可以在
代碼中立即加入必要的工具。我們也用不著顧慮建立這種工具是不是值得, 因為這太容易
了, 太簡單了。這樣子不知可以節省多少時間啊。
你好, Lisp
到此刻為止, 我們所知的關于Lisp的指示可以總結為一句話: Lisp是一個可執行的語法更
優美的XML, 但我們還沒有說Lisp是怎樣做到這一點的, 現在開始補上這個話題。
Lisp有豐富的內置數據類型, 其中的整數和字符串和其他語言沒什么分別。像71或者
"hello"這樣的值, 含義也和C++或者Java這樣的語言大體相同。真正有意思的三種類型是
符號(symbol), 表和函數。這一章的剩余部分, 我都會用來介紹這幾種類型, 還要介紹
Lisp環境是怎樣編譯和運行源碼的。這個過程用Lisp的術語來說通常叫做求值。通讀這一
節內容, 對于透徹理解元編程的真正潛力, 以及代碼和數據的同一性, 和面向領域語言的
觀念, 都極其重要。萬勿等閑視之。我會盡量講得生動有趣一些, 也希望你能獲得一些
啟發。那好, 我們先講符號。
大體上, 符號相當于C++或Java語言中的標志符, 它的名字可以用來訪問變量值(例如
currentTime, arrayCount, n, 等等), 差別在于, Lisp中的符號更加基本。在C++或
Java里面, 變量名只能用字母和下劃線的組合, 而Lisp的符號則非常有包容性, 比如, 加
號(+)就是一個合法的符號, 其他的像-, =, hello-world, *等等都可以是符號名。符號
名的命名規則可以在網上查到。你可以給這些符號任意賦值, 我們這里先用偽碼來說明這
一點。假定函數set是給變量賦值(就像等號=在C++和Java里的作用), 下面是我們的例子:
set(test, 5) // 符號test的值為5
set(=, 5) // 符號=的值為5
set(test, "hello") // 符號test的值為字符串"hello"
set(test, =) // 此時符號=的值為5, 所以test的也為5
set(*, "hello") // 符號*的值為"hello"
好像有什么不對的地方? 假定我們對*賦給整數或者字符串值, 那做乘法時怎么辦? 不管
怎么說, *總是乘法呀? 答案簡單極了。Lisp中函數的角色十分特殊, 函數也是一種數據
類型, 就像整數和字符串一樣, 因此可以把它賦值給符號。乘法函數Lisp的內置函數, 默
認賦給*, 你可以把其他函數賦值給*, 那樣*就不代表乘法了。你也可以把這函數的值存
到另外的變量里。我們再用偽碼來說明一下:
*(3,4) // 3乘4, 結果是12
set(temp, *) // 把*的值, 也就是乘法函數, 賦值給temp
set(*, 3) // 把3賦予*
*(3,4) // 錯誤的表達式, *不再是乘法, 而是數值3
temp(3,4) // temp是乘法函數, 所以此表達式的值為3乘4等于12
set(*, temp) // 再次把乘法函數賦予*
*(3,4) // 3乘4等于12
再古怪一點, 把減號的值賦給加號:
set(+, -) // 減號(-)是內置的減法函數
+(5, 4) // 加號(+)現在是代表減法函數, 結果是5減4等于1
這只是舉例子, 我還沒有詳細講函數。Lisp中的函數是一種數據類型, 和整數, 字符串,
符號等等一樣。一個函數并不必然有一個名字, 這和C++或者Java語言的情形很不相同。
在這里函數自己代表自己。事實上它是一個指向代碼塊的指針, 附帶有一些其他信息(例
如一組參數變量)。只有在把函數賦予其他符號時, 它才具有了名字, 就像把一個數值或
字符串賦予變量一樣的道理。你可以用一個內置的專門用于創建函數的函數來創建函數,
然后把它賦值給符號fn, 用偽碼來表示就是:
fn [a]
{
return *(a, 2);
}
這段代碼返回一個具有一個參數的函數, 函數的功能是計算參數乘2的結果。這個函數還
沒有名字, 你可以把此函數賦值給別的符號:
set(times-two, fn [a] {return *(a, 2)})
我們現在可以這樣調用這個函數:
time-two(5) // 返回10
我們先跳過符號和函數, 講一講表。什么是表? 你也許已經聽過好多相關的說法。表, 一
言以蔽之, 就是把類似XML那樣的數據塊, 用s表達式來表示。表用一對括號括住, 表中元
素以空格分隔, 表可以嵌套。例如(這回我們用真正的Lisp語法, 注意用分號表示注釋):
() ; 空表
(1) ; 含一個元素的表
(1 "test") ; 兩元素表, 一個元素是整數1, 另一個是字符串
(test "hello") ; 兩元素表, 一個元素是符號, 另一個是字符串
(test (1 2) "hello") ; 三元素表, 一個符號test, 一個含有兩個元素1和2的
; 表, 最后一個元素是字符串
當Lisp系統遇到這樣的表時, 它所做的, 和Ant處理XML數據所做的, 非常相似, 那就是試
圖執行它們。其實, Lisp源碼就是特定的一種表, 好比Ant源碼是一種特定的XML一樣。
Lisp執行表的順序是這樣的, 表的第一個元素當作函數, 其他元素當作函數的參數。如果
其中某個參數也是表, 那就按照同樣的原則對這個表求值, 結果再傳遞給最初的函數作為
參數。這就是基本原則。我們看一下真正的代碼:
(* 3 4) ; 相當于前面列舉過的偽碼*(3,4), 即計算3乘4
(times-two 5) ; 返回10, times-two按照前面的定義是求參數的2倍
(3 4) ; 錯誤, 3不是函數
(time-two) ; 錯誤, times-two要求一個參數
(times-two 3 4) ; 錯誤, times-two只要求一個參數
(set + -) ; 把減法函數賦予符號+
(+ 5 4) ; 依據上一句的結果, 此時+表示減法, 所以返回1
(* 3 (+ 2 2)) ; 2+2的結果是4, 再乘3, 結果是12
上述的例子中, 所有的表都是當作代碼來處理的。怎樣把表當作數據來處理呢? 同樣的,
設想一下, Ant是把XML數據當作自己的參數。在Lisp中, 我們給表加一個前綴'來表示數
據。
(set test '(1 2)) ; test的值為兩元素表
(set test (1 2)) ; 錯誤, 1不是函數
(set test '(* 3 4)) ; test的值是三元素表, 三個元素分別是*, 3, 4
我們可以用一個內置的函數head來返回表的第一個元素, tail函數來返回剩余元素組成的
表。
(head '(* 3 4)) ; 返回符號*
(tail '(* 3 4)) ; 返回表(3 4)
(head (tal '(* 3 4))) ; 返回3
(head test) ; 返回*
你可以把Lisp的內置函數想像成Ant的任務。差別在于, 我們不用在另外的語言中擴展
Lisp(雖然完全可以做得到), 我們可以用Lisp自己來擴展自己, 就像上面舉的times-two
函數的例子。Lisp的內置函數集十分精簡, 只包含了十分必要的部分。剩下的函數都是作
為標準庫來實現的。
Lisp宏
我們已經看到, 元編程在一個類似jsp的模板引擎方面的應用。我們通過簡單的字符串處
理來生成代碼。但是我們可以做的更好。我們先提一個問題, 怎樣寫一個工具, 通過查找
目錄結構中的源文件來自動生成Ant腳本。
用字符串處理的方式生成Ant腳本是一種簡單的方式。當然, 還有一種更加抽象, 表達能
力更強, 擴展性更好的方式, 就是利用XML庫在內存中直接生成XML節點, 這樣的話內存中
的節點就可以自動序列化成為字符串。不僅如此, 我們的工具還可以分析這些節點, 對已
有的XML文件做變換。通過直接處理XML節點。我們可以超越字符串處理, 使用更高層次的
概念, 因此我們的工作就會做的更快更好。
我們當然可以直接用Ant自身來處理XML變換和制作代碼生成工具。或者我們也可以用Lisp
來做這項工作。正像我們以前所知的, 表是Lisp內置的數據結構, Lisp含有大量的工具來
快速有效的操作表(head和tail是最簡單的兩個)。而且, Lisp沒有語義約束, 你可以構造
任何數據結構, 只要你原意。
Lisp通過宏(macro)來做元編程。我們寫一組宏來把任務列表(to-do list)轉換為專用領
域語言。
回想一下上面to-do list的例子, 其XML的數據格式是這樣的:
<todo name = "housework">
<item priority = "high">Clean the hose</item>
<item priority = "medium">Wash the dishes</item>
<item priority = "medium">Buy more soap</item>
</todo>
相應的s表達式是這樣的:
(todo "housework"
(item (priority high) "Clean the house")
(item (priority medium) "Wash the dishes")
(item (priority medium) "Buy more soap"))
假設我們要寫一個任務表的管理程序, 把任務表數據存到一組文件里, 當程序啟動時, 從
文件讀取這些數據并顯示給用戶。在別的語言里(比如說Java), 這個任務該怎么做? 我們
會解析XML文件, 從中得出任務表數據, 然后寫代碼遍歷XML樹, 再轉換為Java的數據結構
(老實講, 在Java里解析XML真不是件輕松的事情), 最后再把數據展示給用戶。現在如果
用Lisp, 該怎么做?
假定要用同樣思路的化, 我們大概會用Lisp庫來解析XML。XML對我們來說就是一個Lisp
的表(s表達式), 我們可以遍歷這個表, 然后把相關數據提交給用戶。可是, 既然我們用
Lisp, 就根本沒有必要再用XML格式保存數據, 直接用s表達式就好了, 這樣就沒有必要做
轉換了。我們也用不著專門的解析庫, Lisp可以直接在內存里處理s表達式。注意, Lisp
編譯器和.net編譯器一樣, 對Lisp程序來說, 在運行時總是隨時可用的。
但是還有更好的辦法。我們甚至不用寫表達式來存儲數據, 我們可以寫宏, 把數據當作代
碼來處理。那該怎么做呢? 真的簡單。回想一下, Lisp的函數調用格式:
(function-name arg1 arg2 arg3)
其中每個參數都是s表達式, 求值以后, 傳遞給函數。如果我們用(+ 4 5)來代替arg1,
那么, 程序會先求出結果, 就是9, 然后把9傳遞給函數。宏的工作方式和函數類似。主要
的差別是, 宏的參數在代入時不求值。
(macro-name (+ 4 5))
這里, (+ 4 5)作為一個表傳遞給宏, 然后宏就可以任意處理這個表, 當然也可以對它求
值。宏的返回值是一個表, 然后有程序作為代碼來執行。宏所占的位置, 就被替換為這個
結果代碼。我們可以定義一個宏把數據替換為任意代碼, 比方說, 替換為顯示數據給用戶
的代碼。
這和元編程, 以及我們要做的任務表程序有什么關系呢? 實際上, 編譯器會替我們工作,
調用相應的宏。我們所要做的, 僅僅是創建一個把數據轉換為適當代碼的宏。
例如, 上面曾經將過的C的求三次方的宏, 用Lisp來寫是這樣子:
(defmacro triple (x)
`(+ ~x ~x ~x))
(譯注: 在Common Lisp中, 此處的單引號應當是反單引號, 意思是對表不求值, 但可以對
表中某元素求值, 記號~表示對元素x求值, 這個求值記號在Common Lisp中應當是逗號。
反單引號和單引號的區別是, 單引號標識的表, 其中的元素都不求值。這里作者所用的記
號是自己發明的一種Lisp方言Blaise, 和common lisp略有不同, 事實上, 發明方言是
lisp高手獨有的樂趣, 很多狂熱分子都熱衷這樣做。比如Paul Graham就發明了ARC, 許多
記號比傳統的Lisp簡潔得多, 顯得比較現代)
單引號的用處是禁止對表求值。每次程序中出現triple的時候,
(triple 4)
都會被替換成:
(+ 4 4 4)
我們可以為任務表程序寫一個宏, 把任務數據轉換為可執行碼, 然后執行。假定我們的輸
出是在控制臺:
(defmacro item (priority note)
`(block
(print stdout tab "Prority: " ~(head (tail priority)) endl)
(print stdout tab "Note: " ~note endl endl)))
我們創造了一個非常小的有限的語言來管理嵌在Lisp中的任務表。這個語言只用來解決特
定領域的問題, 通常稱之為DSLs(特定領域語言, 或專用領域語言)。
特定領域語言
本文談到了兩個特定領域語言, 一個是Ant, 處理軟件構造。一個是沒起名字的, 用于處
理任務表。兩者的差別在于, Ant是用XML, XML解析器, 以及Java語言合在一起構造出來
的。而我們的迷你語言則完全內嵌在Lisp中, 只消幾分鐘就做出來了。
我們已經說過了DSL的好處, 這也就是Ant用XML而不直接用Java的原因。如果使用Lisp,
我們可以任意創建DSL, 只要我們需要。我們可以創建用于網站程序的DSL, 可以寫多用戶
游戲, 做固定收益貿易(fixed income trade), 解決蛋白質折疊問題, 處理事務問題, 等
等。我們可以把這些疊放在一起, 造出一個語言, 專門解決基于網絡的貿易程序, 既有網
絡語言的優勢, 又有貿易語言的好處。每天我們都會收獲這種方法帶給我們的益處, 遠遠
超過Ant所能給予我們的。
用DSL解決問題, 做出的程序精簡, 易于維護, 富有彈性。在Java里面, 我們可以用類來
處理問題。這兩種方法的差別在于, Lisp使我們達到了一個更高層次的抽象, 我們不再受
語言解析器本身的限制, 比較一下用Java庫直接寫的構造腳本和用Ant寫的構造腳本其間
的差別。同樣的, 比較一下你以前所做的工作, 你就會明白Lisp帶來的好處。
接下來
學習Lisp就像戰爭中爭奪山頭。盡管在電腦科學領域, Lisp已經算是一門古老的語言, 直
到現在仍然很少有人真的明白該怎樣給初學者講授Lisp。盡管Lisp老手們盡了很大努力,
今天新手學習Lisp仍然是困難重重。好在現在事情正在發生變化, Lisp的資源正在迅速增
加, 隨著時間推移, Lisp將會越來越受關注。
Lisp使人超越平庸, 走到前沿。學會Lisp意味著你能找到更好的工作, 因為聰明的雇主會
被你與眾不同的洞察力所打動。學會Lisp也可能意味著明天你可能會被解雇, 因為你總是
強調, 如果公司所有軟件都用Lisp寫, 公司將會如何卓越, 而這些話你的同事會聽煩的。
Lisp值得努力學習嗎? 那些已經學會Lisp的人都說值得, 當然, 這取決于你的判斷。
你的看法呢?
這篇文章寫寫停停, 用了幾個月才最終完成。如果你覺得有趣, 或者有什么問題, 意見或
建議, 請給我發郵件coffeemug@gmail.com, 我會很高興收到你的反饋。