我從Icon編程語言中所學到的

在 20 世紀 70 年代末和 80 年代初期，Icon 編程語言主要由拉爾夫·格里斯沃爾德（Ralph Griswold）所設計的。在 60 年代，格里斯沃爾德負責過第一個專門用于處理文本的編程語言 ――Snobol（String Orientated Symbolic Language）。Icon 是基于 Snobol 思想而設計的下一代語言，然而它更加統一和完整。

　　在很多方面﹐Icon 是第一個“腳本語言”。它是一種非常高級別，具備出色的能力去處理文本數據并與其環境相結合的語言。迄今為止，它都是如此超前，這也許是它從沒有很流行的一個原因。早在 Perl 和 TCL（這些語言開啟了腳本語言的熱潮）崛起之前好幾年，它就已經出現了。

　　對于一個泡在 BASIC、Fortran、PL/I、Pascal 和C里成長起來的人，Icon 就是個徹頭徹尾的異類。然而它教會了我許多至今都很有用的東西。

　　空集（Nullology）

　　當你調用一個 Icon 函數，它會做以下兩件事之一：它可以返回一個值，或者它會失效。失效聽上去類似于現代的異常處理機制，但是 Icon 的失效有以下幾個不同。首先，當一個 Icon 函數失效時，沒有指標說明它為什么失效。再者，失效是預期的。它總在發生，而且是 Icon 工作方式的一個重要部分。（它有一個單獨的、原始的、針對真正異常條件的錯誤處理機制。）

　　許多 Icon 的函數都是生成器（generator）――它們可以返回多個值。在某些情況下，Icon 將持續調用該函數直到它失效。所以在 Icon 里，失效真正的意思是“沒有更多的值”。例如，下面是一個完整的 Icon 程序，把它的輸入復制到它的輸出：

every write (read ())

　　子句 Every 表示“這樣做直到它失效”。write ()把它的參數寫到標準輸出，read ()從標準輸入返回連續的行，最終在達到文件結束時失效。

　　在C語言里，失效通常被一些特殊保留的返回值，或者其他特設機制所表示（那些失效指標都太容易被遺漏）。直接從C轉到 Icon 后，上面那個小程序驚醒了我，讓我見識到了簡潔、傳神的美感。

　　第一課

　　重要的是去區分有和沒有。或者是一個函數的返回值，或者是一個變量的值，重要的是要能說“沒有一個”。

　　這一課幫我在幾年后認識到異常，也使我領會到其它語言，例如 Lisp, Smalltalk, Ruby 和（在某種程度上）Java，它們的變量包含可以為空的引用，而不是直接存儲數據。

　　一致性（Uniformity）

　　Icon 是第一個讓我用表達式語言做嚴肅工作的語言。也就是說，Icon 沒有語句，只有包含結果值的表達式。我第一次看到這個：

sign := if count > 0 then 1 else -1

　　起初我真的很困惑，但很快我就明白是怎么回事。在 Icon 里，我所用來思考的“if 語句”事實上只是一個“if 表達式”，就像在別處一樣，它會有一個結果值。為什么不應該呢？我曾經思考過這個問題，語句和我所熟悉的語言里的表達式之間的區別好像是人為的和任意的。進一步使用 Icon 的經歷證明了這一點。這當然可能造成濫用構造，產生費解的代碼。但是有時它們正是你做正確的事情所需要的。

　　第二課

　　通常情況下，你認為根本不相同的事情事實上完全相同。不要想當然認為你在某處學到的就是普遍真理。

　　這么多年來，這一課幫助我用許多新東西迅速武裝我的頭腦，包括語言，工具，編程范式和平臺。

　　事實（Truth）

　　我已經提到了生成器和失效的語義。然而一旦你有可以返回多個值甚至失效的表達式，就出現一個問題­――類似 E1 E2 這樣的表達式是什么意思？在多個值有意義的上下文，你可能需要一個定義；但是在傳統環境下，你可能需要一個不同的。所以看起來熟悉的結構就像人們所習慣的。我不會討論細節（畢竟這不是一節 Icon 課），但是 Icon 設計師們能夠找到一個能工作在傳統結構和新結構兩種情況下的表達式，Icon 思路共存，沒有特殊情況。所以，你可以做所有這些事情：

if (i = 1 i = 0) then ...if i = (10) then ...
every write (read ("header") read ("body") read ("footer"))

　　并且它們實現你所期待的。在上例中，“”像一個連接操作符，結果是連接那三個文件。但是操作符的實際語義是不變的――所有這三個例子使用單一的“”定義，結合生成器，表達式失效和目標導向評估。

　　第三課

　　我們所受的關于編程的教育正如我們所學的科學――很方便想到世界是如何真正運轉，但事實是我們就是不知道。科學給予我們的是似乎能解釋世界的理論，因為它們符合所有我們所能想到的實驗。但是隨著我們對世界的了解不斷擴大，遲早我們會認識到之前的理論只是一個近似。一旦事情變得足夠快，足夠大，牛頓是不夠的，我們需要愛因斯坦。（然后它們變得足夠小，我們就需要普朗克和波爾）。單值函數，布爾邏輯是足夠的，但當把生成器投向混合后，你就需要更多地東西。

　　這節課已經幫了我很多次去處理復雜、混亂、有時前矛后盾的商業規則和需求。受 Icon 例子的啟發，我經常成功找到更深、更簡單、更普遍的規則，能作為純粹的變化支持所有表面的合并。

　　表達（Representation）

　　當遇到 Icon 時，我還是一個 Unix 用戶，我已經相當精通用作文本模式的正則表達式。Icon 有一種極其復雜的文本模式機制，不是基于正則表達式，但是實際上更強大。（經過 Perl 6 幾層經典正則表達式添加，Perl 的正則表達式最終實現了威力相當于 Icon 模式的功能。但那是另一個故事了。）

　　語言和協議往往用看起來像簡單的算數表達式的語法來描述：

　　X := T T "+" X
　　T := E E "*" T
　　E := "x" "y" "z" "(" X ")"

　　（僅支持變量x， y 和z的加法和乘法。）

　　盡管很強大，但不可能實現一個像使用經典的正則表達式那樣的語法解析器。（如果你以某種方式成功，也將會非常困難去維護和擴展該解析器。）

　　但是使用 Icon 的可編程模式機制，你可以實現這樣的解析器：

procedure X ()
suspend [T()] [T()， ="+"， X ()]
end

procedure T ()
suspend [E()] [E()， ="*"， T ()]
end
　  
procedure E ()
suspend [="x" ="y" ="z"] [="("， X ()， =")"]
end

　　哇！這看起來就像語法！事實上會真的很容易去用語法編寫程序以生成解析器！

　　你可以這樣調用它：

parseTree = line ? {X()}

　　Icon 里的 yacc 是一個為期一天的黑客。

　　第四課

　　語法很重要。如果語法適合問題域（problem domain），程序則很容易理解。這就是為什么如果一種語言要很好的處理繁雜的數據時，即使它是一個危險的語言功能、容易被濫用，但操作符重載是必不可少的。強大的正則表達式看上去就像“正則表達式”。

　　這一課讓我知道什么時候去寫一點特定領域語言，而不是試圖擠入我現有語言的領域。（通常這是一個很容易的事情。）它把我推向動態的、可塑的語言，如 Ruby（我敢說還有 Lisp）更主流的東西。

　　（語法很重要這一課也大大加強――但以消極的方式――在每次我使用 XSLT 時。幸運的是，很快我就能使用 XQuery 去做所有現在得用 XSLT 去做的工作。）　

英文原文：What I Learned from Icon　翻譯：@dryrun  譯文鏈接