第四章 細部設計／解決問題
───────────────────────────────────────
無關緊要的是：我知道該怎麼做，只是不知道要費時多久。 重要的是：我毫無線索，不知該如何做它！
－摘錄自維幾尼亞工藝學院及州立大學化學學院 實驗室自動化及儀器設計系發展出的作業哲學
一旦決定了應用程式中的元件，下一步就是去設計它們。本章中，我們將討論如何 將解決問題的技巧用在符式程式的細部設計上。這時是純粹發明的時刻，也是我們大多 數人覺得最有趣的部份。每次跟人激辯重要的問題而獲勝，那份志得意滿真是別有滋味。 就英語而言，要將一個概念從解釋此一概念的字裡行間分離出來，是相當困難的。 撰寫符式應用程式時，要將細部設計階段從實現（implemention）中分出來也不容易， 因為我們傾向於使用符式來做設計。因此，在本章中我們要稍微超前進度，不僅提出問題 ，也同時設計出問題的解答，從頭到尾，把程式碼實現出來。
解決問題的技巧
即使一個新手，也可能在未曾深思問題的解決技巧之前，就解決了程式設計的問題。 既然如此，學這些技巧的重點何在？一句話，只是為了加快這個過程。思考解決問題的 "方法"，而不考慮問題本身，可以使我們那儲存著各種技巧的潛意識倉庫充實起來。 G.Polya對問題解決之道有許多著作，尤其是數學上的問題。其中最為人津津樂道的 著作為〈How to Solve it〉一書[1]。雖然解決數學問題和解決軟體問題並不十分相似， 但你卻能由其中發現頗有價值的建議。
下面一系列的提示綜合了一些由解決問題這門科學所推薦的技巧：
─────────────────────────────────────
提示 定出你的目標。
─────────────────────────────────────
確知你要完成的是什麼。就如第二章中所討論的，此一步驟尚可細分如下： 決定資料介面：要知道達成此一目標所需的資料是什麼，而且要確定它們是可獲得的 （輸入）。也要知道什麼資料是此一功能所應該產生的（輸出）。對單一個定義而言，這 就是要寫出堆疊效果的註解（stack-effect comment）。 決定規則：溫習你所知道的全部事實。在第二章中我們描述了計算電話費的費率， 也伴隨著描述出使用費率的規則。
─────────────────────────────────────
提示 要對問題有一整體的概念。
─────────────────────────────────────
在分析階段中，我們將問題分開為若干部份，以便澄清我們對各個單件的瞭解。現 在我們卻進入綜合階段。必須將問題做為一個整體來看。 設法儘可能地將問題有關的資訊都一併納入你的心中。藉著詞、片語、圖表或任何 能表示資料或規則的圖形，來幫助你在一眼之下能看到最多之資訊。讓心中擠滿有關 問題所應達成的需求，就像不斷地吸氣入肺。 接著，你要保持住這份心智的影像，正如彆氣一般。 下述兩種情況之一將會發生： 你或許靈機一動就見到了解決方案。太好了！不妨吐口大氣，輕鬆片刻，儘管直接地 進入實現的階段。或者 ...，問題太複雜或太生疏了，沒那麼容易解決。在這種情形下， 你必須將注意力轉向類似的事情及部份的解決方案上（partial solutions）。當這樣做 的時候，重要的是你已經全神貫注於問題有關之需求事項上，並且將它印在心中。
─────────────────────────────────────
提示 發展出一個計劃
─────────────────────────────────────
如果解決方案未曾在一眨眼之間出現，下一步就要決定解決它所需採取的途徑。要 定出行動方針，切忌毫無目標，胡亂摸索。 下面的提示建議了一些你可以參考的方法：
─────────────────────────────────────
提示 考慮類似的問題。
─────────────────────────────────────
此一問題似曾相識？你是否曾經寫過像這樣的定義？想想看問題中有哪些部份是你所 熟悉的？不同之處在那裡？試著回憶起你以前是如何解決那個問題的，或是如何解決那 個類似問題的。
─────────────────────────────────────
提示 向前做。（work forward）
─────────────────────────────────────
要攻擊一個問題，正常而明顯的方式是從已知的部份著手，向未知的部份推進。若 不知該押哪匹馬，何不從研究牠們的近況著手，了解牠們目前的健康狀況等等，從許多 不同的因素中權衡輕重，挑選你的寵兒。
─────────────────────────────────────
提示 反方向進行。（work backward）
─────────────────────────────────────
越複雜的問題，有愈多種處理輸入資訊的可能方式。你如何知道哪條路徑能帶你接近 解決之道？你無從得知。這類問題最好從相反的方向著手解決（圖4-1）。
圖4-1 從相反方向著手比較容易
┌─────────────────────┐
││┌───────┬──────────┐│
└┘ ─────┐│ ─────────┤│
入口 ┌─────┐│└─────────┐ │
│││┌───┐│└─────────┐├─┘
│││└── │├──┬──────┐│ ┌┐ 出口
││└────┘│ ─┘ └─┘│
└┴──────┴─────────────┘
─────────────────────────────────────
提示 要有信心。
─────────────────────────────────────
從反方向著手，信心是個必要條件。我們藉著一個頗有名氣的數學問題來說明。 假設有兩個水桶（圖4-2），桶上並未刻有任何容積的刻度，只知道大桶可裝9加侖， 小桶可裝4加侖。我們的工作是要用這兩個桶從小河中確實地量出6加侖水來。
圖4-2 兩個水桶
試著先自己去解答這個問題，然後再繼續讀下去。 我們如何從9和4得出6來？不妨先向前做下去（working forward），心裡默默地將水 從一個桶倒入另一桶。譬如，如果將小桶水倒入大桶兩次，我們就會得到8加侖。若將 大桶裝滿，再自大桶向小桶注水裝滿，我們在大桶就可以得到5加侖。 這種想法很有趣，但是並不能讓我們得到6，也不容易看出怎樣才可以得到6加侖。 讓我們試著從相反方向下工夫，假設我們已經量出6加侖水，這些水當然在 大桶中（小桶裝不下！）。現在要問，我們是怎麼將這些水放進去的？在這個狀態的前 一步，兩個桶的狀況又是如何？ 只有兩種可能（圖4-3）：
1. 小桶（4加侖）當時是滿的，而且我們剛剛將小桶的水倒入大桶內。這暗示 那時候的大桶應該有2加侖水。或 .... 2. 大桶（9加侖）當時是滿的，而且我們剛剛從大桶將3加侖的水倒入小桶。
那一項選擇是對的？不妨猜猜看。第一項選擇需要一個2加侖之量度；第二選擇 需要一個3加侖之度量。在剛才的倒水遊戲中，我們從未見過2這樣的單位，卻見過 1這個差值（5減4），而4減1是3 。讓我們選第二項。
圖4-3 得出最後的結果
真正的訣竅是，我們必須使自己深信不疑，我們的確已經達到了上述的狀況。我們 才剛從大桶向小桶倒了3加侖水。拋開一切的懷疑，集中心力在"我們是如何做到的"。 你怎能從大桶中倒出3加侖水到小桶中？除非小桶中已經裝有1加侖水！我們突然間 跳出困境。如今，簡單的問題是，我們如何能讓小桶裝有1加侖的水？要做到這一點， 就必須從大桶裝滿9加侖水開始，向小桶倒4加侖水兩次，大桶就剩下1加侖。然後將 此1加侖水倒入小桶中。 最後一步應該是再前向進行一次，以驗證我們的邏輯。 從反向下工夫另有一個好處：如果問題是無解的，你就能早些証明這點。
─────────────────────────────────────
提示 認識附屬問題（auxiliary
problem）。
─────────────────────────────────────
在一個問題尚未解決之前，我們對於應該採取什麼步驟 --或需要幾個步驟-- 都只有 糢糊的概念。等問題漸漸熟悉之後，我們才開始發現，我們的問題包含有一個或幾個子問 題，而它們與所建議採取的步驟的主要輪廓似乎並不一樣。 在剛才解決的問題中，我們看出了兩個子問題：讓小桶裝進1加侖水，然後讓大 桶裝進6加侖水。 認出這些較小的問題（或稱附屬問題）是解決問題的重要技巧。經由識別出這種 附屬問題，我們就能假設問題會有直接了當的解決方案。我們帶著主要的問題勇猛直前， 用不著停下來決定那個解決方案可能會是何等模樣的。 （我們將會發現，符式是很適合這種技術的。）
─────────────────────────────────────
提示 後退一步去看這個問題。
─────────────────────────────────────
我們常會太過於情緒化而堅持著某一個特定的解決方法不放，竟然忘了要保持開闊 的心思。 "解決問題"一類的文章經常會引用"九個點"的問題為例。它曾經令我目瞪口呆過， 所以我也將它依樣地寫出來。有九個點按著圖4-4的方式排列著。目標是，要你畫出直 線，去碰到或穿過所有的九個點，但筆尖不可離開紙面。問題的限制是：最多只能畫 四條直線。
圖4-4 九個點的問題
你也許會枯坐好一陣子，畫出的結果也許強不過圖4-5。如果你真費心的做過它， 或許最後會下結論，認為這是個玩笑 --根本無解。
圖4-5 不完全的解答
但你若坐直了身體，問問自己： 「我是否因為太侷限於自己狹窄的思路而走錯了方向，欺騙了自己？我是否劃地自 限，設想了一些問題中並不存在的限制？那些限制會是些什麼？」 然後，你或許會想到把某些直線延伸到那些點所在的範圍之外。
─────────────────────────────────────
提示 用你的整個大腦來思考。
─────────────────────────────────────
當某一問題使你束手無策時，你要輕鬆下來，不必耽心它，甚至要暫時忘掉它。 有創作力的人都經常注意到，他們最好的點子似乎來自床上或浴室。書本上也建議， 遭遇真正困難問題時，不妨訴諸潛意識。 時下對腦部功能的理論，正努力探索理性的意識思想與潛意識思想之間的差異。 （前者係依靠對符號的運作；後者則相關於對原先已儲存的資訊的理解，並將知識以新 的、有用的方式重新組合及聯繫。） Leslie Hart[2]說明依邏輯方式解決大型問題的難處：
巨大的負荷被加諸於人腦一小部份的區域上（意識區）。從那裏，它們能夠被帶往 注意區（attention zoon）一段時間。這點在技術上是可能的，正如馬戲中的雜耍一樣 ，但要花費相當大的時間和努力，才能做到。較為合理的做法似乎是 ... 去利用我們那 神奇的潛意識區的完整資源 ... 腦部億萬個細胞儲存之場所。
... 你的工作就是供應人腦原始的輸入資料，例如經由觀察、閱讀、資料之蒐集、 並參考其他人所取得的資訊。一旦有了輸入，潛意識就自動地、同時地在注意區之外接手 去做。
... 明顯地是 ... 在這段時間，某種搜索行動進行著，縱然不一定是連續不斷，卻 很像一部大型電腦內部的情況。我寧可斷言的冒險猜測，這種全面搜索的行動不停地分 枝出去，動動又停停，碰到死巷就又重新來過，最後終於蒐獲到某一答案，經評估後， 將之砰然一聲拋到意識上的注意區內 --其細節之詳細，常令人格外震驚。
─────────────────────────────────────
提示 評估你的解決方案。找尋其它的解決方案。
─────────────────────────────────────
你或許已經發現活捉蟑螂的方法。但是，一定還有其它的方法，其中有些甚至更好。 不要在你的第一個解決方案上投資太多，而根本不問你自己是否還有第二種選擇。
訪問一位軟體發明家
───────────────────────────────────────
Scientek Instrumentation Inc公司的總裁Donald A. Burgess說：
我有幾項技巧很管用，多年來，不論設計任何東西，它們都能使我保持彈性。第一條 規則是，"沒有不可能的事" 。第二條規則是，"別忘了，目標是賺錢"。
首先要查驗你的問題，在紙上先規劃出兩三種進行的途徑。然後試試那最有趣的途 徑，看看是否行得通。繼續做完它。然後故意回到起點，從頭到尾再做一遍。
從頭來過有兩層價值。第一，它給你一個新的嘗試。你或許會循著老方法再走一遍， 但也可能會走出一條新路來。
第二，這個新嘗試可能會顯示出各種有力的可能性。現在你有了一個比較點。你可以 觀察新舊兩種方法，比較兩者的優劣點。你已經可以在一個較好的位置來做判斷。
受困的原因多半來自於固執地走那單一的路徑。記得要說：「我要這部柳橙榨汁 機有所不同。我要甩掉那毫無趣味的傳統設計。讓我們試試一些瘋狂的主意。」
最棒的事是開始畫圖。我畫一些小人。畫小人能使它看來不像"資料"，也不會 干擾我的思考。人的心智特別適合工作於類比的東西。在文句中塗鴨能使你從語言 的侷限中脫困而出，即使符式語言也不例外。
當我要集中注意力時，我就在小紙片上畫圖。當我要考慮大方向時，或要捕捉全局 的流程時，我就用大張紙來畫圖。這些就是使我免於受困所用的點子之一。
當我要用符式語言去寫程式時，我會先花掉一天，儘量做白日夢，儘量在那些念 頭之間打轉。通常，在我開始輸入以前，已經先寫出了一個大綱。其中並沒有程式 碼，只有談話。那是用來提醒我自己的註記。
然後我從最後一列程式碼開始寫起。描述出我想做的事，並且儘可能地寫得像英文。 然後用編輯器將這個定義移到檔案最底部，再開始定義其中所用到的每個字。之後， 可能我會認為這種做法是愚蠢的，或許我就把最後的那個詞一分為二，將其中之一 移到前面，以便能早些用到它。若手邊有硬體，我就執行；若沒有，我就模擬它。
符式需要自律。你必須停止跟鍵盤胡鬧的這類事。符式心甘情願地去做我叫它做的事 ，我會叫它做各種可笑的事，而那些事根本和我要進行的事無關。每當到這種時候， 我就必須離開鍵盤。
符式讓你去玩。那倒也不錯，因為你有機會得到一些概念。但是要記得，不要玩成了
習慣。不管怎麼說，在發明東西這件事上，你的頭腦比起電腦來是好得太多了。
───────────────────────────────────────
細步設計
如今身處在發展週期中之某一點，我們已經決定需要某一個元件（或某一特定的詞） 。這個元件是由一群詞組成，其中某些詞 --它們構成詞集-- 會被另一些元件所使用 （通稱為外部定義），而另一些詞 --內部詞（inner word）-- 則僅被使用於此一元件 之中，（通稱為內部定義）。 要儘量地造出你所需要的詞，以符合下面的提示：
─────────────────────────────────────
提示 每個定義都必須行使一個簡單而清晰完整的任務。
─────────────────────────────────────
以下是有關元件設計的一般性步驟：
1. 依功能上的需要，來決定外部定義的名稱及語法（為介面下定義）。 2. 藉著描述演算法及資料結構，以精煉概念性模型。 3. 認出輔助定義（auxiliary definitions）。 4. 決定何種輔助定義及技術是已經可取得的。 5. 以虛擬程式碼來描述演算法。 6. 從現存的定義開始，反向進行到輸入的部份，以實現這個元件。 7. 實現任何遺漏的輔助定義。 8. 若詞集內含有許多名字，它們含有很大的相同部份。則應該先將這些共同部份設 計好，並寫成內部定義，然後再去實現這些外部定義。
我們先對前兩個步驟深入探討，再做一個詞集設計之範例。
符式語法
在發展週期中的這一點上，你必須決定新詞集中的詞將如何地被使用在文句中。在 這樣做的時候，要記著 --這個詞集將來是要被後來的元件所使用的。
─────────────────────────────────────
提示
設計一個元件時，目標是去建造一個能使你爾後的程式碼既容易讀、也容易維護的 詞集。
─────────────────────────────────────
在設計元件時，心中應該存著有使用這個元件的元件們。你必須設計詞集的語法，以 使這些詞在文句中出現時，都是有其意義的。就如我們所知，隱藏起元件中彼此相關聯 的資訊，可以保証良好的可維護性。 同時，也要注意符式自己（核心）本身的語法。與其堅持某個語法，只因它似乎是你 所熟悉的，倒不如選擇符式能夠支援的語法。這樣，你也許就可以免去寫一大堆不必要 的程式碼的麻煩。 以下是符式的自然語法（natural syntax）中的一些基本規則：
─────────────────────────────────────
提示 讓數字出現在名字之前。
─────────────────────────────────────
凡需要數值做為引數（argument）的詞自然盼望能在堆疊上得到那個數值。在語法上 說來，當然，數字就應該處身於名字之前。以『個空格』一詞（它送出"n"個空格）的 語法為例：
20 個空格
此一規則偶爾會冒犯我們已經耳熟的字序。舉例來說，符式字『+』盼望它所需要的 兩個引數都處身其前：
3 4 +
此種"數值在運算子之前"的次序稱為「後位表示法」（postfix）。 符式，以其大肚量而言，並不"堅持"這種後位表示法。你可以重新定義『+』，讓它 盼望會有一個數字出現在輸入字串（input stream）中，正如下所示：
3 + 4
它的定義為：
: + 空格碼 取詞 轉為雙整數 DROP + ;
（其中『取詞』係依79/83年標準。它會傳回一個地址，而『轉為雙整數』會傅回 一個雙整數值）。 雖然不錯，但是你卻無法在其它冒號定義中使用這個定義，或者傳遞它的引數。因 而糟塌了符式語言的主要優點。 經常的情形是，"名詞"形式的字會將它的地址（或任何類型之指標）以堆疊引數的 方式傳送給"動詞"形式的字。下面這種模樣的語法
"名詞" "動詞"
已經証實，經由堆疊的使用，它是最容易實現的。 有時候這種字序聽來不太順耳。舉例來說，假設我們有個名叫『庫存』的檔案。我 們能對它做的一件事，就是將它的資料以整齊漂亮的行列格式顯示出來。若『庫存』傳 送一個指標給『展示』，而『展示』按照這個指標來做動作，這樣的語法就是：
庫存 展示
若你要的是像英文般的字序，符式也能讓你辦到。但多半會涉入新的複雜度。有 時，最好辦法還是選個較好的名字。下面這個名字如何？
庫存 報表
（我們使"指標"變成一個形容詞，而"動作者"卻變為名詞。） 如果規格上堅持要使用這樣的語法：
展示 庫存
我們也還能有好幾種選擇。『展示』可以設定一個旗標，而『庫存』依照旗標行動。這 種方式有其缺點，尤其是『庫存』必須聰明到能夠知道所有可能採取的一切行動。（第七 及第八章將會討論到此一問題。） 或者，『展示』也可能從輸入字串中查看那跟在後面的下一個字。我們將在本章後半 部的一個提示 --避免期待-- 中討論這種方式。 或者，以我們所推薦之方式：『展示』可以設定一個"執行變數"，然後『庫存』再去 執行它。（我們在第七章將討論向量指引的執行方式。）
─────────────────────────────────────
提示 讓文句跟在名字後面。
─────────────────────────────────────
假若符式解譯器發現本文中的某個字串，既非數值，也不是已經定義過的字，它便 送出一個錯誤訊息並立即停止解譯的動作。因此，一個未經定義的字串就必須跟在一個 已經定義了的詞之後。 例如『."』這個字，它出現在要被列印的字串之前。另一例是『建造』，（就如同 所有其它的"定義字"一樣），它必須處身於等待著被定義的名稱之前。 此一規則也同樣地適用於你只是要參考，而不是像往常一樣去執行的這種已經定義過 的詞。以『忘掉』這個詞為例，
忘掉 工作
從語法上來說，『忘掉』必須出現在『工作』之前，以使『工作』不會被執行。
─────────────────────────────────────
提示 讓定義用掉它們的引數（argument）。
─────────────────────────────────────
此一語法規則，與其說是符式的嗜好，倒不如說是一種良好的符式程式設計的規範。 假如你正在寫『發射』一詞，它需要發射台的編號來發射那個火箭。你希望定義的 模樣看來像：
: 發射 ( 發射台編號 -- ) 載入 瞄準 點火 ;
三個內部定義的每一個都需要同樣的一個引數，也就是發射台的編號。你在某個地方需要 『複製』。問題是，在那裏？如果你把它們放在『載入』及『瞄準』裡面，你就能讓 它們不出現在『發射』的定義內，就像上面的方式。如果你讓它們留在『載入』及『瞄準 』之外，你就必須定義成：
: 發射 ( 發射台編號 -- ) 複製 載入 複製 瞄準 點火 ;
依照約定，第二個定義比較好，因為『載入』和『瞄準』的定義會比較"乾淨"。它們就能 夠祗做你要它們做的事。如果你另外需要一個『準備』，你就能這樣地定義它：
: 準備 ( 發射台編號 -- ) 複製 載入 瞄準 ;
而不會將它定成奇怪的：
: 準備 ( 發射台編號 -- ) 載入 瞄準 丟掉 ;
─────────────────────────────────────
提示 使用以零為起算點的計數方式。
─────────────────────────────────────
我們人類對東西編號總是習慣從一開始："第一，第二，第三"等等。另一方面，依 數學上的模式，若由零開始，卻反而是比較自然的。因為電腦是一種數字處理器，如果 我們從零開始計數，寫起軟體來就會方便的多。 為了說明這點，假設我們有一個每個記錄欄位都是8個字元的『表格』。第一個欄位 佔著表中的最前8個字元。我們將『表格』加上0以計算出它的起始位址。第二個欄位的地 址，則是將『表格』加8而得之。
圖4-6 欄位寬度為8個字元的表格
表格
┌──────┐
│ 第一欄位 │
├──────┤
│ 第二欄位 │
├──────┤
要得出下面的推算公式並不難：
第一個欄位起始於： 0 * 8 = 0 第二個欄位起始於： 1 * 8 = 8 第三個欄位起始於： 2 * 8 = 16
我們可以輕易地定出一個字，它會將某一個欄位號碼轉換為該欄位的起始地址：
: 欄位 ( 欄位號碼 -- 地址 ) 8 * 表格 + ;
以電腦的術語來說，稱"第一個欄位"為第0個欄位就頗有道理了。 如果規格中要求數字由1開始，那也容易。你儘管在你的設計中一直以0為起始做 下去，然後，僅僅在『使用者詞集』（亦即最後使用者所能用到的那套字）中，加上 能將"以0為起始"轉換為"以1為起始"的詞：
: 項目 ( n -- 地址 ) 1- 欄位 ;
─────────────────────────────────────
提示 讓地址出現在數目之前。
─────────────────────────────────────
同樣的，這也是個習慣上的約定，並非符式的規格。但此一約定卻攸關程式碼的可讀性。 你會從『印字串』（TYPE），『清除』（ERASE），以及『空白』（BLANK）等詞，發現 這種規則的例子。
─────────────────────────────────────
提示 讓來源（source）出現在目的（destination）之前。
─────────────────────────────────────
這又是另一個為可讀性而設下的約定。譬如，在某些系統中常可見到下面的片語
22 37 拷貝
意指將第22冪拷貝到第37冪。『字元移動』（CMOVE）的語法則遵循了此一約定和前一 約定：
( --來源 目的 長度) 字元移動
─────────────────────────────────────
提示 要避免（對輸入字串中）有所期望（expectation）。
─────────────────────────────────────
一般而言，儘量避免建出一種字，它在執行的時候，要期待輸入字串中有某些字存在。 假設你的彩色電腦是以1代表藍色，以9代表淡藍色。你想定義出二個詞：『藍色』 將會傳回1；『淡』可以出現在『藍色』之前以產生9 。 在符式中，你可以將『藍色』定義為一個常數，執行時就一定傳回1 。
1 常數 藍色
然後再將『淡』定義為：它在執行時，會從輸入字串中去尋找下一個詞，執行它並 將結果和8 "OR"起來。（在本書稍後的地方，再度討論這個例子時，它的邏輯關係會變 得比較清楚）：
: 淡 ( 出現在顏色之前 ) ( -- 代表顏色的數值 ) 挑出 執行 8 OR ;
（給初學者：在『淡』的定義內的『挑出』（在英文符式中，是符號 ' ，讀作"tick"） 一詞是一個搜尋字典的詞；它會帶著一個名稱到字典中去尋找，並傳回此詞在字典中所 在的執行地址。在此處，它會找到跟在後面的那個詞 --譬如『藍色』-- 的地址，並將 此一地址傳送給『執行』，『執行』就會去執行『藍色』，並將結果"1"推到堆疊上。 再來就是將8和1 "OR" 起來產生9。） 當這個定義被使用在解譯狀態下的輸入字串中時，它是能正確的工作。但若我 們要在一個冒號定義中使用『淡』，卻需要經過特殊的處理。例如：
: 編輯 淡 藍色 外框 ;
即使是在輸入字串中，若不小心跟了一個沒定義過的字在後面，『執行』這個詞在執行時 就有可能造成當機。 若你非要使用這樣的語法不可，較好的辦法是讓『淡』去設定一個旗標，再由『藍 色』來判定那個旗標（這在下文中會有交代）。 有時，也的確是有需要到輸入字串中去搜尋的，甚至還是必要的。（還在審議中的 "TO"這個字就經常使用這種方式來實現[3]）。 總而言之，要避免期待。否則，你會自找沒趣。
─────────────────────────────────────
提示 讓字去做它自己的事。
─────────────────────────────────────
這條規則跟"避免期望"是一對搭檔。它是符式哲理上的俏皮話 --"讓字去做它們自 己的工作，不要讓它多管閒事"。不妨對符式的編譯器（它的功能就是編譯冒號定義）稍 做觀察，並且參閱漫畫式的圖4-7。它祗有很少的幾個規則：
在輸入字串中分離出下一個詞，並到字典中去查尋它。 若是一般的詞，則"編入"它的地址。 若是"立即字"（immediate ），就執行它。 若不是一個已經定義過的字，就設法將它轉變為數值，並將它編入。 若也不是一個數值，就送出一個錯誤訊息並中止這個過程。
圖4-7 傳統編譯器與符式編譯器的比較
以上的句子並未提到『如果, 否則, 然後』等編譯詞（compiling-word）。"冒號 編譯器"自己並不了解每個詞，它只認得某些"立即詞"，並且會執行它們，讓它們去 做它們自己該完成的工作。（參閱Starting FORTH第11章 --如何控制"冒號編譯器"） 編譯器甚至也不用去"尋找"那個用來停止編譯的詞 --分號(;)-- 以便能停下來。 它祗需要去執行這個詞（這是一個立即詞），讓它結束定義並關掉編譯器的工作。 這種做法有兩項重大的優點。首先，這種編譯器因此變的非常簡單，只要幾列的程 式碼即可完成。其次，隨你高興添加多少編譯用的字都行，只要將它們定義為"立即詞" 即可。如此一來，符式的冒號編譯器也變成是可擴充的！ 符式的本文解譯器（text interpreter）及地址解譯器（address interpreter）也 都秉持著這個規則。 下面的提示或許是本章中最重要的。
─────────────────────────────────────
提示 當你能使用符式所提供的解譯器／編譯器時，就不要去寫你自己的。
─────────────────────────────────────
每一個等級（class）的應用程式都各自需要一種特殊用途（special purpose）的 語言 --那是一組自給自足的命令，能用來完成一件特定的事。組合語言就是一個例子。 在那兒，你有一大組的命令，也就是助憶符號，可以用來描述出你所需要的機械碼。再 一次地，符式又從這種哲學的主流中躍身而出。 傳統的組譯器（assemblers）都是一些特定用途的解譯器 --也就是說，它們都是極 為複雜的程式，對組合語言程式的列表進行掃描，以便找出它所認得的那些助憶符號， 如ADD, SUB, JMP等等，再將它們組合出相對應的機器指令。但符式的組譯器卻不然，它 不過是由一些字組成的詞集而已，而那些字自己就能組合出所需要的機器碼。 特殊用途語言的例子頗多，每一個都各自適用在一種特別的應用上。例如：
1. 如果你正寫一個探險式的遊戲，你會想寫出一種語言，它能讓你用來建造並描述 那些巨獸和房間等等。你或許會建造一個叫做『房間』的定義詞，它的用法如下：
房間 地牢
然後再造出一組字，藉著建立一些和房間有關的資料結構，去描述出房間的屬性：
東邊有 龍穴 西邊有 木橋 內有 金幣 ..等等
這些製作遊戲所用的語言中的那些命令，簡單的說，就是符式的詞，而符式本身就 是這個語言的解譯器（interpreter）。 2. 若你的工作中使用到"可編程陣列邏輯裝置"（PAL），你會需要某一種形式的符號 表示法，讓你能根據輸入腳位（pin）的狀態，以邏輯上的項（term）去描述輸出腳 位的行為。Michael Stolowitz曾經用符式語言寫出一份非常簡潔的PAL編譯器[4]。 3. 若你必須寫出一系列的使用者選單（user menus），來操作你的應用程式，你也許 會需要先發展出一套編譯選單用的語言。這個語言中的字允許一個應用程式的設計師 很快地編寫出他所需要的選單 --同時也將如何畫出欄框，如何移動游標等等的資 訊隱藏起來。
上面這些例子都可以在符式中，使用平常的符式解譯器，編寫成一個詞集，而不需 要為此寫出一個特定用途的解譯器或編譯器。
───────────────────────────────────────
Moore說：
簡單的解答就是那種不會讓不相干的東西遮住你的問題的解答。你也許可以料到，在 問題中的某些地方，會需要用到一個獨特的解譯器。但當你每次看到一個獨特的解 譯器時，它也就暗示著，還有一些特別曖昧不明的東西在問題內。但無論怎麼說， 是絕對不需要你自己來寫一個解譯器的。
如果你寫出你自己的解譯器，它幾乎可以確定，將會是你整個應用程式中最複雜、最 費心力的地方。你本來是要寫個應用程式，但現在卻一變而成為寫一個解譯程式。
我想程式設計師是喜歡寫解譯程式的。他們就是喜歡這種費力勞神的工作。但總有 一天，這個世界（也許是你的老板）將會要你丟掉那些你正在寫的鍵盤處理及二進
制轉換程式，並要你開始真正的去解決問題。
───────────────────────────────────────
演算法與資料結構
在第二章，我們曾學到如何以介面及規則來描述一個問題的需求。在這一節，我們 將要精鍊（refine）每個元件的概念性模型，將它變成為一個有明確定義的演算法及資 料結構。 演算法是一種程序，可以被描述成一組有限數目的規則，用來完成某項工作。這些 規則必須是不曖昧的（unambiguous），並保證能在有限次數的應用之後會終止 （terminate）。 演算法介於兩種東西之間，一種是不很精確的人類語言的命令，譬如"請將信件 按年代整理好"，另一種則是精確的電腦語言指令，如『開始 雙複製 小於 如果 ...』 等等。將信件依日期先後整理的演算法看來也許像這樣：
1. 取一封尚未整理的信件在手，查看其日期。 2. 找出與手上信件同年同月的信件夾。 3. 翻查信件夾中的信件，從最前面開始，直到發現比你手上的信件的日期為晚的 第一封信為止。 4. 將手上的信件插到日期稍晚的那封信之前。（若信件夾為空夾，則逕自將該信件 放入即可。）
當然，同一件工作可能有好幾種不同的演算法可以完成，上述的方法在處理信夾中 只有十封或更少的信件時還不錯，但若信夾中有百封信件，你可能就要另找一個更有 效率的演算法才合適。例如：
1.（同前例） 2.（同前例） 3. 若日期是在前半月，則從信件夾三分之一處打開。若該處的那封信的日期比你手 上的信件為晚，就向前找，直到你發現與你手上信件同日期或比它稍晚的信件 為止。就在那一點將信件插入。若所發現之信件日期比手上的信件為早，則向 後查 ...
... 相信你已看出重點。第二種演算法比前者要複雜得多，但在執行時，平均所需 的步驟卻較少（因為你不必每次都從信夾的起頭去一封一封地找），做起來當然比較快。 資料結構是資料或資料位址的一種安排，為了問題的需要而特別地予以組織。在 上例中，檔案櫃裡有信件夾，信件夾裡有一封一封的信件，這種安排就可以看作是一種 資料結構。 因此，概念性模型就包括：檔案櫃和信件夾（資料結構），再加上歸檔的步驟（演算 法）。
計算 vs. 資料結構 vs. 邏輯
如前所說，問題的最佳解決方案是那個最簡單而又最合適的一個；不論任何問題， 你都應極力追求那最簡單的途徑。 假定我們必須寫出程式碼，以合乎下列規格：
若輸入引數為1 ，則輸出為10 若輸入引數為2 ，則輸出為12 若輸入引數為3 ，則輸出為14
有三種途徑可供我們採用：
計算（calculation ）
( n1 --n2 ) 1- 2* 10 +
資料結構（Data Structure）
建造 表格 10 編入字元 12 編入字元 14 編入字元
( n1 -- n2) 1- 表格 + 讀取字元
邏輯（Logic ）
( n1 -- n2) 條件分枝
1 分枝 10 分枝結束
2 分枝 12 分枝結束
3 分枝 14 分枝結束
條件結束
對此一問題，計算是最簡單的。姑且假定它也是合適的（速度無關緊要），則計算可以說是最好的一種。
將角度轉為正弦及餘弦函數的問題，計算比用資料結構要簡單得多（至少在原始程式碼的行數及目的碼的大小上來說是如此）。但是對於許多需要三角函數的應用程式而言，從記憶體中的表格去找答案卻比較快。在這種情形下，簡單而又合適的解決方案應該是採用資料結構的方式。
以第二章中的電話收費為例。在該問題中，費率似乎沒有什麼規則，於是我們設計了一個資料結構：
全 額 低 額 最低額
───────────────────────────
第一分鐘 .30 .22 .12
───────────────────────────
後續每分鐘 .12 .10 .06
───────────────────────────
使用資料結構比起為了計算而發明一個公式要簡單得多。而且計算公式到頭來說不定 還會被驗證是錯誤的。以本例而言，以表格驅動的程式碼在維護時也比較方便。 第三章中，我們藉著判斷表（decision table），為小小編輯器設計了一個按鍵解譯 器程式：
--按鍵-- --非插入模式-- --插入模式--
Ctrl-D 刪除 離開插入模式
Ctrl-I 進入插入模式 離開插入模式
退位鍵 指標後退 向左刪除
etc.
我們本來也可以藉邏輯達到同樣的結果：
條件分枝
CNTRL-D 分枝 插入模式旗標 讀取
如果 離開插入模式 否則 刪除 然後 分枝結束
CNTRL-I 分枝 插入模式旗標 讀取
如果 離開插入模式 否則 進入插入模式 然後 分枝結束
退位鍵 分枝 插入模式旗標 讀取
如果 向左刪除 否則 指標後退 然後 分枝結束
條件結束
但邏輯會讓人覺得比較困擾。對於這種在多重條件下，以邏輯來描述的演算法而言， 若在原始設計中沒有使用表格來作註解，則更會令人天旋地轉。 當結果無法用計算得到，或是判斷並沒有複雜到非用判斷表不可的時候，邏輯的使用 才值得鼓勵。本書的第八章就是專為減少程式中邏輯的使用而寫的。
───────────────────────────────
提示 選擇某種途徑去解決問題時，不妨依下列的優先次序考慮：
1. 計算（需要執行速度時除外） 2. 資料結構 3. 邏輯
───────────────────────────────
當然，模組化的語言，例如符式，好處之一就在於：某一個元件的實際運作 -- 不論使用計算、資料結構、或是邏輯--
對於應用程式中的其餘部份並不一定是可見的。
解決一個問題：羅馬數字的計算
在這個部份，我們要示範一個詞集的設計過程。除了將問題和答案呈現出來之外，我 也希望能一起將問題打散開來。（當初解決問題時的思考脈絡，我全都記錄下來了）。 你會見到先前提到的有關解題的指引，同時也會見到，它們的使用並非全按章法，甚至 看上去有相當偶然的零亂 --就像是在真實的過程中一樣。 現在開始：問題是要寫出一個定義，它會取用堆疊上的一個數值，將之以羅馬數字 表示出來。 這個問題頗能代表大型系統中的一個元件。在解決問題的全程中，我們可能會定義出 一些字來，包括一些資料結構。但這個特定的詞集僅含有一個會被外界使用的名字， 『羅馬數值』，它將自堆疊取得所需的引數。（其它的字都是此一元件的內字） 在決定了外部的語法之後，我們就可以向下進行演算法及資料結構的設計。 我們將遵循科學的方法 --先觀察事實，將解決方案模型化，並依照事實去測試 它，再修正我們的解決方案。我們將從回憶對羅馬數值所知的事實開始。 說實話，我並不記得有關羅馬數值組合的正式規則。但你若給我一個數值，我卻能用 它去造出一個羅馬數值來。我們知道怎麼做 --但目前還無法明確說出這個演算的程序。 既然如此，何不先看看那最先的10個數字：
I
II
III
IV
V
VI
VII
VIII
IX
X
首先作一些觀察。第一，這其中有痕記（tally ）的概念，在那裏我們用一些記號 來代表一個數字（3 = III ）。而另一方面，特殊符號被用來代表一個群（ 5 = V ）。 事實上，在一行上我們似乎不能有超過三個 I 的情況，再來就必需使用一個較大值的 符號。 第二，在5的前後有對稱的現象。5有一個專用符號"V"，10也有一個專用符號"X"。 I，II，III 這些圖案在後半段又新重現，但有一個V在前面。 比5少1寫成IV，而比10少1寫成IX。意思似乎是，在較大值符號前加個"I"就是 指"比 ... 少1"。 這些都是隱晦不清的觀察事實，但沒關係。我們到目前為止還沒有整個全貌。 且看10以上又是怎樣的：
XI
XII
XIII
XIV
XV
XVI
XVII
XVIII
XIX
XX
這跟前面的圖案完全相同，只不過在前面另加一個"X"而已。因此，10也有一個 同樣的重複週期。 假如我們檢視20這組，它們也是一樣，只不過用了兩個"X"而已。30這組就用了三 個"X"。事實上，"X"的數目就是十進位數值中的十位數的數字。 這似乎是一項相當重要之觀察：我們可以拆解十進制的數值為各單個位數的數字 （digit），而且可以分開地對待每個位數。例如37可以寫成
XXX （30）
後面跟著
VII （7）
這似乎有點言之過早，但我們已看出一種方法，藉著它，符式能讓我們將數值分解為 單個數字 --藉著以10做"帶餘數的除法"（module division）。例如，我們說
37 10 /~FBBB1;餘
那是讓37被10除，我們在堆疊上得到一個7和一個3（3是商數，在堆疊的頂端）。 但是這些觀察卻也引來一個問題：10以下的該怎麼辦？在那兒並沒有十位數的數字。 這是個特例嗎？好吧，如果我們認為每個"X"代表一個10，那麼沒有"X"不就代表0嗎。 因此，這並不算是特例。我們的演算法還是可行的，甚至對10以下數值也是可行的。 且讓我們繼續觀察，特別要注意10的週期。我們注意到40是"XL"。這跟4是"IV" 相似，只不過移位了一個10倍的值而已。當"X"出現在"L"之前，可以說成"比50少10"。 相似的情形還有
L (50) 類似於 V (5)
LX (60) 類似於 VI (6)
LXX (70) 類似於 VII (7)
LXXX (80) 類似於 VIII (8)
XC (90) 類似於 IX (9)
C (100) 類似於 X (10)
很明顯的，這種相同的圖案可以適用於任何一個位數的數字
--只是符號改變而已。 不論如何，很清楚的，現在我們是在跟一個相當重要的十進位系統打交道。
如果真有這個需要，我們甚至可以為一個系統去構建一個模型，它能藉著演算法和 資料結構來顯示從1到99的羅馬數值。
資料結構
~FBBB1;個位數表~I; ~FBBB1;十位數表~I;
────── ──────
0 0
1 I 1 X
2 II 2 XX
3 III 3 XXX
4 IV 4 XL
5 V 5 L
6 VI 6 LX
7 VII 7 LXX
8 VIII 8 LXXX
9 IX 9 XC
演算法
將n（1-99）除以10的結果，其商數就是十位數的數字，餘數就個位數的數字。 以商數自十位數表中查出，並印出那些符號，以餘數自個位數表中查出，並也印出 那些符號。 例如，若數值為72，商就是7 ，餘數是2 。在十位數表中對應7的符號是"LXX"， 所以將它印出。在個位數的表中對應2的符號是"II"，也將它印出。結果就是：
LXXII
我們剛建造出一個能適用於1到99的模型。再高一層的數值就需要一個百位數表， 並且第一次使用的除數是100。 剛才描述的邏輯模型也許還算令人滿意，只要它能完成工作就行。但是看起來好像 並沒有徹底的解決問題。我們不過是在一連串的表內儲存著所有可能出現的組合，而避開 了如何去產生基本圖樣的主題而已。在本章稍早之處，我們就已經觀察到，如果可能的 話，用計算的方式以獲得答案，會比使用資料結構來的簡單。 由於本節原本就是在探討如何建構演算法，何不乾脆找出一個通用的演算方法 --就 是找出一種使用一組基本符號就能產生任意位數的數值的演算法。我們的資料結構應 該只含有下列的資訊：
(一字輩) (五字輩)
(個位) I V
(十位) X L
(百位) C D
(千位) M
在列出這些符號的同時，我們也將它們依照某種正確的方式"組織"起來。左縱列 的符號都是10的倍數；右縱列的符號都是5的倍數。還有，各行的符號值都是上一行符號 值的10倍。 不同的一點是，左列的符號可以重複的組合在一起，例如"XXXIII"。但右列的符號 卻不允許這麼做，譬如"VVV"。看出這點有用處嗎？誰知道？ 我們姑且將左列符號通稱為"一字輩"（ONERS），右列符號通稱為"五字輩（FIVERS） 。一字輩代表的值為1，10，100，及1,000；也就是1在各個位數的值。五字輩代表5，50 ，及500；也就是5在各個位數的值。 採用這種稱謂，而不使用符號本身，我們就能描述出產生任何數字（digit）的演算 法。（我們已經從各種類的符號中，分解出真正的符號。）例如，我們可以說出初步的 演算法：
對任一個數字（digit），印出所需要的一字輩符號的數量，直到它們相加之和等於 該數值為止。
因此，300就得到"CCC"； 20得到"XX"； 1得到"I"； 而321就得到"CCCXXI"。 此一演算式一直有效，直到數字為4時失效。現在我們的演算法必須擴展以涵蓋此 一例外：
對任一個數位，印出所需要的一字輩符號的數量，直到它們相加之和等於該數值為 止。但若該數字為4 ，則印出一個一字輩，然後再印出一個五字輩。
因此，40就是"XL"； 4就是"IV"。
這個新規則可以適用，直到數字為5時失效。正如前面所見，數字為5或以上時，它先以 一個五字輩的符號開始。因此我們再度擴展我們的規則如下：
若數字為5或以上時，你要從一個五字輩開始，並從該值減去5； 否則就什麼都不 做。然後，再印出所需要的一字輩符號的數量，直到它們相加之和等於該餘值為止。 但若該數字為4 ，則印出一個一字輩，然後再印出一個五字輩。
這一規則可以使用，直到數字為9時失效。在這種情形下，我們應該印出一個一字輩，在 一個..什麼之前？高一位數的那一行的一字輩之前。讓我們稱它為"十字輩"（TENER）。 於是我們的完整模型就應該是：
若數字為5或以上時，你要先從印出一個五字輩開始，並從該值減去5；否則就什麼 都不做。然後，再印出所需要的一字輩符號的數量，直到它們相加之和等於該餘值 為止。但若該數字為4 ，則印出一個一字輩，然後再印出一個五字輩。或者， 若它是個9 ，則要印出一個一字輩及一個十字輩即可。
因此，90就是"XC"； 9就是"IX"。
如今，我們總算得到一套"語言版"的演算法。但還有一些步驟需要完成，才能拿到電腦 上去執行。 特別是，必須要注意那些例外的處理。絕不可草率的說：
我要你做甲，乙，及丙。但是在某某狀況下，你要做另外一些不同的事。
因為電腦會在了解那些"但是"之前，已經先做了甲，乙，及丙。 反而是，我們必需先檢查，看看是否這些例外在我們要做一些什麼之前，就已經 成立了。
───────────────────────────────
提示 在構建一個演算法時，例外是最後才去考慮；但在撰寫程式碼時，你首先要處理 的就是那些例外。
───────────────────────────────
這告訴我們關於那個產生羅馬數值的定義大體結構上的一些事。一開始就必須先去測 試那4和9的例外。不論是其中的哪一種狀況，它都要能妥當地反應。若兩種例外都未 碰上，就遵照"正常的"演算法去做。我們使用虛擬程式碼可寫出：
: 數字轉換 ( n-- ) 4或9 如果 ..特例處理.. 否則 ..正常處理.. 然後 ;
有經驗的符式程式設計師不會實際地寫出這種虛擬程式碼，他多半是在心中建立出這 種結構的影像，以處理例外的情況。經驗不夠的人或許會籍著圖表的幫助去抓住這種 結構，或是像我們一樣，寫出類似上面的虛擬程式碼。 在符式中，我們總會設法減少對邏輯之依賴。但是在本例中，我們需要條件式的 『如果』，因為我們有個例外要處理。雖然如此，我們仍然已經將控制結構的複雜性 減到最低，就是在定義中將『如果 ... 然後』限制到只有一個。 不錯，我們仍然需要在4的例外和9的例外二者間有所判斷，但是我們已經將那個結構 延後到較低階層的定義中再處理 --也就是測試4或9以及 ..特例處理..的那些碼中。 我們的結構實際上所表達的意思是：不論"4的例外"或"9的例外"，都必須禁止正常 情況的執行。祗是測試每個例外是不夠的，譬如下面錯誤的寫法：
: 數字轉換 ( n-- ) 4的情況 如果 一字輩 五字輩 然後
9的情況 如果 一字輩 十字輩 然後
..正常處理.. ;
因為正常情況的處理一定會被執行到。 若堅持一定要分開處理"4例外"和"9例外"，我們可以安排讓它們各自傳送一個 旗標，以表示例外發生了。只要兩個旗標中的任何一個為真，我們就可以排除"正常處 理"：
: 數字轉換 ( n-- ) 4的情況 如果 一字輩 五字輩 然後
9的情況 如果 一字輩 十字輩 然後
或 不是 如果 ..正常處理.. 然後 ;
但這個方式卻不必要地增加了新的控制結構，而使定義趨於繁複。我們暫且將它擱下， 仍用原來的那種。 現在我們對於主定義的結構總算有了一個大略的概念了。 我們宣稱，「若數字為5或以上時，你要從一個五字輩開始，並從該值減去5； 否則 就什麼都不做。然後，再印出所需要的一字輩符號的數量，直到它們相加之和等於該餘值 為止。」 將這些規則直譯為符式，其模樣如下：
( n--) 複製 4 > 如果 五字輩 5 - 然後 一字輩們
這在技術上是正確的，但我們若熟悉除法，我們會將它看作是除以5的自然情況。如 果我們讓數字除以5，當數字小於5時，其商為零（假）；當數字在5與9之間，其商 為1（真）。我們可以利用商做為布林旗標（boolean flag），讓它們來決定我們是否 需要那個前置的五字輩：
( n-- ) 5 / 如果 五字輩 然後 ...
這個商（旗標）就變為『如果』的引數。 甚至，除以5之後得到的餘數總是在0到4之間，這意思是說（除了那些例外的情況） ，我們可以直接將餘數當做一字輩的引數。於是可以修改我們的片語為
( n-- ) 5 /餘 如果 五字輩 然後 一字輩們
再回到那個例外的情況。如今我們看出，用一個單一的測試就能測試出4和9二 種情況 --也就是，檢查餘數是否為4。這提醒我們可以先去做『5 /餘』，然後再去測試 例外狀況。就像這樣：
: 數字轉換 ( n-- ) 5 /餘 OVER 4 =
如果 ..特例處理.. 否則 如果 五字輩 然後 一字輩們 然後 ;
（注意，我們複製了餘數，好讓我們能在不失去它的情況下去和4做比較。） 結果我們還是有了一個雙層的『如果 然後』結構。但它看起來蠻合適的，因為這 第二層的『如果 然後』是用來處理例外的情況。另外一點就是：像『如果 五字輩 然後』這麼短的片語，很難說值得將它做成一個單獨分開來的定義。你當然可以那麼做。 （但這裡我們不這麼做。） 且讓我們集中注意到例外處理的程式碼上。描述它的演算方式：「若該數字為4，則 印出一個一字輩，再印出一個五字輩。若它是個9 ，則印出一個一字輩及一個十字輩」 我們可以假定那個數字非4則9，否則我們就不會來到這裡執行這個定義了。問題是， 我們如何知道它是哪一個？ 再一次，我們仍然可以用除5所得到的商。若商為零，它必定是4；不然它就是9。 因此，何不再玩同樣的小技巧，利用商做為布林旗標。我們寫下：
: 特例處理 ( 商 -- ) 如果 一字輩 十字輩 否則 一字輩 五字輩 然後 ;
對這個定義的檢視中我們注意到，我們總是印出了一個一字輩。所以這定義可以被簡 化為：
: 特例處理 ( 商 -- ) 一字輩 如果 十字輩 否則 五字輩 然後 ;
我們原是假定有個商已經被準備好在堆疊上。且讓我們再回到『數字轉換』的定義 上去確定這件事：
: 數字轉換 ( n-- ) 5 /餘 OVER 4 = 如果 特例處理
否則 如果 五字輩 然後 一字輩們 然後 ;
實際是，我們不但有個商數，而且在它下面還有個餘數。我們在執行『否則』的子句 時，這兩者都在堆疊上。『特例處理』這個字，不論怎麼說，它僅僅需要那個商而已。 所以，為求堆疊上的對稱，我們必須丟掉這個餘數：
: 數字轉換 ( n-- ) 5 /餘 OVER 4 = 如果 特例處理 丟掉 否則
如果 五字輩 然後 一字輩們 然後 ;
這樣，我們就有了產生單個數字的羅馬數值的完整程式碼。如果我們等不及，想在 其它的附屬定義完成之前就先試驗一下，我們可以在載入『特例處理』及『數字轉換』 的定義之前，很快地先定義出一個能印出一組符號（譬如針對個位數的那一欄）的詞集：
: 一字輩 ." I" ;
: 五字輩 ." V" ;
: 十字輩 ." X" ;
: 一字輩們 ( 一字輩的數量-- ) ？複製 如果 0 DO 一字輩 LOOP 然後 ;
但我們也沒那麼急。我們所感興趣的是繼續對問題走下去，去定義出一字輩，五字 輩，及十字輩的那些字來，它們能夠依照我們所正在處理的位數，印出正確的符號。 讓我們再回到前不久的那份符號表：
(一字輩) (五字輩)
(個位) I V
(十位) X L
(百位) C D
(千位) M
經觀察發現，我們也需要一個"十字輩" --那就是在一字輩那一欄的下一行。 這樣一來，這個表似乎就有改寫的必要：
看來似乎有點多餘。能避免嗎？或許我們可以試試不同的模型，也許一個線型的 表格，例如：
個位 I
V
十位 X
L
百位 C
D
千位 M
我們可以想像成各欄的名稱（如"個位數"，"十位數"，等等）都指著那一欄的一字 輩。從這兒，只要向下走一格就可以得到各欄的五字輩；而向下走二格就是十字輩。 這正如有三隻手的胳臂一樣。我們可以將它裝在個位數欄，如圖4-8-a所示，也可 以裝在十位數欄，如圖4-8-b 所示，或任何十的倍數的地方。
圖4-8 資料結構的存取 -- 以機械方式表示
有經驗的符式程式設計師當然不會去想像什麼臂或手的那些玩意，但是，在企圖以 程式碼去構建他的模型之前，心中總會有個強烈的影象，而那也就是所謂右腦思考 的東西。 初學者初習右腦思考的方式時，下面的提示或許有所助益：
───────────────────────────────
提示 若你思考某一概念性模型時遭遇困難，就試著將它變成可見的 --或畫出它-- 一種機械式裝置。
───────────────────────────────
我們的表格只是個簡單的文字陣列。由於一個文字只需要一個8位元組，讓我們將每 "欄"定為一個字元寬。我們稱此表為『羅馬符號表』：
建造 羅馬符號表 ( 個位) ASCII I 編入字元 ASCII V 編入字元
( 十位) ASCII X 編入字元 ASCII L 編入字元
( 百位) ASCII C 編入字元 ASCII D 編入字元
( 仟位) ASCII M 編入字元
註：你的系統中若沒有『ASCII』這個字可用（見本書附錄C），也可以用：
建造 羅馬符號表 73 編入字元 86 編入字元 88 編入字元 76 編入字元
67 編入字元 68 編入字元 77 編入字元
藉著同時使用兩個不同的位移值（offset），我們就可以從表中選出一個特定的 符號。一個次元代表位數：個位數，十位數，百位數等等。這個次元被定成是"目前的" （current ），也就是說，會一直保持在這個狀態，直到我們改變它為止。 另一個次元代表目前的位數中，我們所要的那個符號類別 --一字輩，五字輩，或 十字輩。這個次元是不定的，也就是說，每次我們都必須指出所要的那個符號。 讓我們從實現"目前的"次元開始。我們需要某一種方法來指向那"目前的"位數欄。 讓我們造出一個叫做『欄號』的變數，讓它存著表的位移值：
變數 欄號 ( 目前的位移值 )
: 個位 0 欄號 存入 ;
: 十位 2 欄號 存入 ;
: 百位 4 欄號 存入 ;
: 仟位 6 欄號 存入 ;
如今，我們可以經由將變數值加到表的起始地址上（由『羅馬符號表』傳回），以得到 所要的"手臂位置"。
: 行址 ( --地址 ) 羅馬符號表 欄號 讀取 + ;
讓我們看看是否能做出顯示一個符號的字。我們從『一字輩』這個字開始。 我們在『一字輩』中所想做之事是印出一個文字符號。
: 一字輩 .... 印字元 ;
往回做，『印字元』需要堆疊上有一個『ASCII』字元。我們如何將它放在那兒？使用 『讀取字元』。
: 一字輩 ... 讀取字元 印字元 ;
『讀取字元』需要那個存有我們所要符號的地址。我們如何得到該地址？ 『一字輩』是那可移動的胳臂上第一隻"手"，也就是『行址』正指著的。所以 我們所要的地址就是『行址』所 傳回的：
: 一字輩 行址 讀取字元 印字元 ;
然後，我們再定義『五字輩』。它在取出那個符號並送出它之前，計算那同一個"行"的地 址，然後再加上1去得到下一行：
: 五字輩 行址 1+ 讀取字元 印字元 ;
而『十字輩』則為：
: 十字輩 行址 2+ 讀取字元 印字元 ;
這三個定義是相當重複的，因為它們之間唯一的不同只是那個改變的位移值，我們可 從定義中分解出那個位移：
: 印出符號 ( 位移值 --) 行址 + 讀取字元 印字元 ;
現在可以定義如下：
: 一字輩 0 印出符號 ;
: 五字輩 1 印出符號 ;
: 十字輩 2 印出符號 ;
現在剩下來的工作就只剩將一個完整的十進位的數值拆解，使它變成一些單個位數的數 字。根據我們所做過的觀察，這點應該是簡單的。圖4-9列出了完整程式的列表。 太妙了！從問題開始，到概念性模型，到程式碼。 注意：此一解決方案並非是最佳化的。本書並不談論最佳化這個題目。 另外一個想法：依使用者不同的需要，我們或許得加上錯誤檢查的能力。我們實際 所知最高值的羅馬符號為M；所能顯示的最大數值是3,999，或"MMMCMXCIX"。 我們也許會修飾『羅馬數值』這個字成為：
: 羅馬數值 ( n--) 複製 3999 > 放棄並印出" 數值過大！" 羅馬數值 ;
───────────────────────────────────────
Moore說：
當你有了正確無誤的感覺時，那你已經做對了。也許就是那種感覺讓符式與其它語 言有所不同，你在其它那些語言中從沒有"你是真正的做對了"的感覺。在符式中，那就 是一種"萬歲！"的反應。然後你衝出大門，巴不得天下人都知道這回事。
當然囉，沒有人會像你那般欣喜若狂。
───────────────────────────────────────
圖4-9 已經解決了的羅馬數值問題
\ 羅馬數值的轉換 建造 羅馬符號表 ( 個位) ASCII I 編入字元 ASCII V 編入字元 ( 十位) ASCII X 編入字元 ASCII L 編入字元 ( 百位) ASCII C 編入字元 ASCII D 編入字元 ( 仟位) ASCII M 編入字元 變數 欄號 ( 存著目前的位移值 ) : 個位 0 欄號 存入 ; : 十位 2 欄號 存入 ; : 百位 4 欄號 存入 ; : 仟位 6 欄號 存入 ; : 行址 ( --地址 ) 羅馬符號表 欄號 讀取 + ;
: 印出符號 ( 位移值 --) 行址 + 讀取字元 印字元 ;
: 一字輩 0 印出符號 ;
: 五字輩 1 印出符號 ;
: 十字輩 2 印出符號 ;
: 一字輩們 ( 數量-- ) ？複製 如果 0 DO 一字輩 LOOP 然後 ;
: 特例處理 ( 商 -- ) 一字輩 如果 十字輩 否則 五字輩 然後 ;
: 數字轉換 ( n-- ) 5 /餘 OVER 4 = 如果 特例處理 丟掉 否則
如果 五字輩 然後 一字輩們 然後 ;
: 羅馬數值 ( n--) 1000 /餘 仟位 數字轉換
100 /餘 佰位 數字轉換
10 /餘 十位 數字轉換
個位 數字轉換 ;
結語
本章中，我們已學到單一個元件的發展，首先從決定它的語法開始，進而決定其中各種演算法及資料結構，最後結束於符式中的實做。
藉著本章，我們完成了設計階段的討論。後面的章節就將討論風格及程式碼的寫作技巧。
參考資料
1. G. Polya, How To Solve It: A New Aspect of Mathematical Method,
( Princeton, New Jersey, Princeton University Press).
2. Leslie A. Hart, How the Brain Works, 1975 by Leslie A. Hart,
( New York, Basic Books, Inc., 1975)
3. Evan Rosen, " High Speed, Low Memory Consumption Structures,"
1982 FORMAL Conference Proceedings, P.191.
4. Michael Stolowitz, " A Compiler for Programmable Logic in FORTH,"
1982 FORMAL Conference Proceedings, P.257.
進一步的思考
設計一個模擬撲克牌洗牌動作的元件並描述其演算法。你的演算法將產生一個數字的陣列，0-51，以隨意的次序安排著。
本問題的限制事項，不說你也知道，當然是不准任何一張牌在陣列中出現兩次。
你可以假設你有一個叫做『選擇』的亂數產生器。它的堆疊的引數是一個"n"； 它能產生從0到 n-1（含）範圍內的一個數值。（參考 Starting FORTH一書，第十章。）
你是否能設計一種洗牌的演算程式，它必須能夠避開在迴路每次循環時，那種對尚末被決定的數值所做的耗時的檢查？你是否能只用一個陣列就做到？