第八章 控制結構的簡化
───────────────────────────────────────
控制結構在符式裡，不像在其它語言那麼重要。符式程式設計師傾向於以簡短的字 寫出複雜的應用程式，而不太去注意像 IF THEN 一類的結構。 有幾種技巧可以減少控制結構的使用。它們是:
• 運算或計算 • 經由重新分解，以便將條件隱藏起來 • 使用結構化的跳出 • 向量化 • 重新設計
在本章中，我們要檢視如何使用這些技巧，以簡化或消除程式碼中的控制結構。
控制結構的壞處在那裡？
在開始腦筋急轉彎之前，讓我們先停一下，解釋為什麼首先要避免使用"條件"。 條件結構的使用會增加程式碼的複雜度。你的程式碼越複雜，就越難閱讀和維護。 一個機械的零件越多，損壞的機會越大，並且越難修理。
───────────────────────────────────────
Moore說了這個故事：
我最近回到幾年前曾經為他們做過一些工作的公司。他們把我叫回去，是因為我寫 的那些程式已經有五年了，並且已經變的很複雜。在這段期間，有幾個程式設計師
曾經進入這個程式，修改了一些指令，加入了一些狀態變數和條件。每一條我所記 得的五年前很簡單的指令，現在卻都變得複雜了。「如果這樣.. 否則如果這樣..
否則如果這樣..」，再來才是那件簡單的事情。 現在讀這些指令，我很難想起來它要做什麼，和為什麼要這樣做。我必需回想每
個變數指的是什麼，它為什麼在這裏，以及它接著會產生什麼，或不產生什麼。 開始的時候，程式設計師很自然的就這樣做了，因為他們有一個特殊狀況需要處理。
為了處理這個特殊狀況，他們先在一個地方放上了條件。然後他們發現，這裡也需 要一個條件，那裡也需要一個條件。結果是，每增加一個步驟，就增加一點程式的
複雜度。因為他們是程式設計師，所以他們也都還能控制它。 結果變得很遭糕。到最後，他們一共有半打的旗標。測試這個，將它恢復，再設定
那個，如此重復不已。在一個條件成立後，會發現還有另外的條件需要檢查。他們 製造了一堆像麵條式的邏輯判斷的程式碼。
程式的複雜度比當初他們想像的要高的多。但是他們還以為這種處理方式是對的， 他們沒想到有一個簡單的解決辦法，就是用兩個字而不是一個字。你可以說 GO 或
者說 PRETEND。 在大部份的應用程式裡，真正需要做條件測試的地方很少。例如在一個遊戲程式中，
你不必說「如果他按下按鈕A，就做這件事；如果他按下按鈕B，就做另一件事」。 你不必經由像這樣的邏輯。
如果他按一個按鈕，你就做一件事。其實你所要做的事是與按鈕相關的，而不是與 邏輯有什麼瓜葛的。"條件"本身並不壞，它們是一種重要的結構。但是一個程式如
果有太多的條件，就會顯得笨拙而難讀。你所要做的是，自問每一個條件是否必需。 遇到一個條件，你就問「我是不是弄錯了什麼？」
你使用"條件"所能做到的事，也可以用另一種方法來達成。從長遠的觀點來看，使用 另一種方法要比使用條件有益的多。
───────────────────────────────────────
在我們沒有介紹技巧的細節之前，先讓我們看一個特殊的例子中，三種不同使用條件 的方式。圖8-1，圖8-2，和圖8-3 列舉了自動櫃員機的三種設計版本。 第一個例子直接來自學校，是給結構化程式設計師的版本。它的邏輯取決於 IF 指 令的正確巢化。 容易閱讀嗎？請你告訴我，在什麼條件下，使用者的卡片會被吃掉。為了回答這個 問題，你必需從底部計算 ELSE 的數目，並將它與從頂部計算的 IF 數目配合，或使用 一隻對齊用的直尺。 第二種版本，圖8-2，是一個在可讀性上有所改進的版本。它使用了許多小的、命了 名的程序。如果卡片的持有人不對，卡片就會被吃掉。 即使有了這個改良，每個字的設計還是完全地依賴著那必須要進行的條件測試上的 順序。看起來像是"最高階層"的程序，卻負擔著要去消除那些最壞情況、最不重要的工 作。而且，每個條件測試又要負責呼叫下一個條件測試。 第三種版本最接近符式的承諾。它最高層的字正確地在觀念上表達出要發生的事， 並且只顯示出主要的路徑。每一個次級字有它自己的錯誤跳出處理，不會混淆了主程式 的閱讀性。而且，一個條件測試也不必一定要呼叫下一個條件的測試。 而且，『處理』是依著下面的事實所設計的：使用者經由按鍵，選擇所需要的服務。 完全不需要做條件測試。一個按鍵可以啟動提款，另一個啟動存款。這種方法也能應付 爾後設計上的可能改變，例如增加自動轉存的功能。（並且，這種方法也因此而不會依賴 硬體。鍵盤的詳細介面可以隱藏在鍵盤的詞集裡，像是『讀取按鈕』和『按鈕』。） 當然，這三種方法符式都可以達成。你願意選那一種呢 ？
圖 8-1 自動櫃員機：結構化的方法
IF 卡片有效 DO
IF 卡的持有人正確 DO
IF 要求提款 DO
IF 提款密碼有效 DO
讀進提款數
IF 要求的提款數 ≦ 目前存款 DO
IF 提款數 ≦ 櫃員機內的現有現金 DO
送出現金
結算賬目
ELSE
顯示信息
停止對話
ELSE
顯示信息
停止對話
ELSE
顯示信息
停止對話
ELSE
IF 提款密碼有效 DO
讀進存款數
從入口接受存款信封
結算賬目
ELSE
顯示信息
結束對話
ELSE
吃掉卡
ELSE
顯示信息
END
圖 8-2 自動櫃員機：在已命名的程序中將條件巢化
PROCEDURE 讀卡片
IF ..卡片是可被讀取的.. THEN 檢查持有人
ELSE ..拒絕卡片.. END
PROCEDURE 檢查持有人
IF ..持有人正確.. THEN 檢查密碼
ELSE ..吃掉卡片.. END
PROCEDURE 檢查密碼
IF ..密碼與持有人符合.. THEN 處理
ELSE ..顯示信息，結束對話.. END
PROCEDURE 處理
IF ..要求提款.. THEN 提款
ELSE 存款 END
PROCEDURE 提款
..詢問.. IF ..要求的提款數目 ?目前存款.. THEN 支付 END
PROCEDURE 支付
IF ..提款數目 ?櫃員機現有現金.. THEN ..送出現金.. 結算賬目..
ELSE ..顯示信息.. END
PROCEDURE 存款
..接受存款信封..
..結算賬目..
圖 8-3 自動櫃員機：重新分解，並且／或者取消條件
: 開始進行 讀卡片 檢查持有人 檢查密碼 處理 ;
: 讀卡片 ..讀入的碼不正常.. IF ..剔除卡片.. 停止 THEN ;
: 檢查持有人 ..持有人身份不符.. IF ..吃進卡片.. 停止 THEN ;
: 檢查密碼 ..密碼不合.. IF ..顯示信息.. 停止 THEN ;
: 檢查按鈕 ( -- 按鈕功能的地址 ) ( 這是一種依機型而有所不同的程序 ) ;
: 處理 讀取按鈕 執行 ;
1 按鈕 提款 2 按鈕 存款
: 提款 ..詢問.. 要求的提款數目 ?目前存款.. IF 支付 THEN ;
: 支付 ..提款數目 ?櫃員機現有現金.. IF ..送出現金.. 結算賬目..
ELSE ..顯示信息.. THEN ;
: 存款 ..接受存款信封.. 結算賬目.. ;
如何消除控制結構
在這一節，我們將研究一些將條件簡化或省略的技術。它們大多會產生可讀性較高的碼，比較容易維護，也比較有效率。有些技術能產生效率較高的程式碼，但可讀性會差一些。
因此，請記住：並非所有的提示，都是可以被使用在各種情況的。
利用詞典
───────────────────────────────────── 提示 賦予每個功能有它自己的一個定義。
─────────────────────────────────────
若能適當地使用符式的詞典，實際上我們並沒有消除"條件"；我們只是將它們從應用程式碼之中分解出來。符式的詞典就是一個巨大的字串的 CASE 敘述。這種「檢查是否吻合並執行」的功能是隱藏在符式系統內的。
───────────────────────────────────────
Moore的觀點：
在我的會計賬簿裡，如果你從某個人收到一張支票，你鍵入金額數目，支票號碼， 『收款』，和開票人姓名：
200.00 N1235202 收款 李志德
『收款』這個詞會做適當的處理。如果你要開票給某個人，你鍵入數目，發票號碼 ，『付帳』，和該人的姓名：
1000.00 DS2440530 付帳 劉金標
...
一個詞代表著一種狀況。由詞典來做決定。
───────────────────────────────────────
這種概念在符式本身就具備了。要相加一對單整數，我們使用指令『+』。要相加一對 雙整數，我們就使用指令『D+』。一種效率較差、較複雜的方法是，一個指令需要"知道" 被加數的種類。 符式很有效率，因為所有這些詞，『收款』、『付帳』、『+』、『D+』等等，都可 以直接被執行，不需要任何的測試和分支。
─────────────────────────────────────
提示 用愚笨的字
─────────────────────────────────────
這不是給電視劇作家的建議。這是使用詞典的另一個例子。"愚笨"的字是那種不依靠狀 態的字，因而，不論在什麼狀況下，它們都有著相同的行為。 一個愚笨的字是不泛義的，也因此比較可以信賴。 有幾個常用的符式字，最近在這方面引起爭議。其中之一是『."』，被用來印出一 個字串。它最簡單的一種形式是，只允許被使用在冒號定義之中：
: TEST ." THIS IS A STRING " ;
實際上，這個版本的字並不"印出"一個字串。它只是編譯一個在執行時真正用來印出字 串的字的地址，以及要被印出的字串本身。 這是這個字的愚笨版本。如果你將它使用在冒號定義之外，它也只會編譯字串，並不 能做出你期望的工作。 為了解決這個問題，在FIG版本的『."』定義中，加上了一個測試，以決定系統目前 是在編譯或解譯的狀態。若是在編譯狀態裡，『."』就將字串和印字串的字的地址編入； 若在解譯狀態裡，它就印出字串。 『."』變成了由兩個完全不同的字，被放在一個 IF ELSE THEN 結構所建構的屋簷 下所組成。被用來指示符式是在編譯或解譯狀態下的旗標稱為『STATE』。因為『."』的 行為決定於 STATE 的值，所以說它是「依 STATE 決定的」（STATE-dependent）。 這個指令在冒號定義的內外，表現出來的行為都相同。這個方法起初看起來似乎很 有用，但是精明的學生很快就看出來，它比看起來要複雜的多。 假設一個學生要寫一個稱為『B."』的新詞，用來在他的顯示幕上顯示出較高亮度的 字串。它能被這樣地使用著：
." INSERT DISK IN " B." LEFT " ." DRIVE "
他或許該定義『B."』為
: B." BRIGHT ." NORMAL ;
也就是，將視訊狀態變的亮些，印出字串，然後再恢復常態。 他試了這個程式碼。影像立刻被摧毀了；幻像破滅；這個定義不工作。 要解決這個問題，程式設計師必需研究它自己的系統裡『(.")』的定義。我不想節外生枝 的在這裡解釋『(.")』的工作原理，我敘述的要點是：看起來的優點，實際上不盡然是 優點。 意外的，用一種不同語法的方式，可以解決這個學生的問題。它不需要兩個分別的 『."』和『B."』來印出字串。只要改變系統的『(.")』，使它在印出之後一定回復正常 狀態，即使它大部份的時間都已經是在正常狀態。利用這個語法，程式設計師只要在 需要加強亮度的字串前，加上一個簡單的字『BRIGHT』。
." INSERT DISK IN " BRIGHT ." LEFT " ." DRIVE "
1983年的標準規定了『."』的笨版本，並且，為了解決需要一個解譯版本的問題，加上了 一個新字『.(』。令人高興的是，有了這兩個字，我們就可以讓詞典來做決定。 字『'』(tick)也有類似的歷史。在FIG的符式版本裡，它是依 STATE 決定，現在已 經在83標準裡被定義成一個笨字。『 '』 和『."』的共同點是，程式設計師能夠在較高 層的定義中使用它們，而它們也會表現的如同正常的情況一樣。
─────────────────────────────────────
提示
如果程式設計師希望從一個高階層的定義中呼叫一個字，並且希望它會表現的像是 在解譯狀態下一樣，那麼這個字的行為就不能是「依 STATE 決定的」。
─────────────────────────────────────
『ASCII』是個依 STATE 決定行為，而又能工作的很好的一個字，MAKE 也是。（參看 附錄C）條件的巢狀化和合併（Nesting and Combining Conditions）
─────────────────────────────────────
提示 不要去測試已經被排除在外的東西。
─────────────────────────────────────
請看這個例子：
: PROCESS-KEY
KEY DUP LEFT-ARROW = IF CURSOR-LEFT THEN
DUP RIGHT-ARROW = IF CURSOR-RIGHT THEN
DUP UP-ARROW = IF CURSOR-UP THEN
DOWN-ARROW = IF CURSOR-DOWN THEN ;
這個版本的效率很差，因為不論其中哪一個情況出現，都必需做全部四種測試。其實 ，如果是左箭號被按下，就不需要再做其它的按鍵檢查。 換一種方法，你可將條件巢化，像這樣：
: PROCESS-KEY
KEY DUP LEFT-ARROW = IF CURSOR-LEFT ELSE
DUP RIGHT-ARROW = IF CURSOR-RIGHT ELSE
DUP UP-ARROW = IF CURSOR-UP ELSE
CURSOR-DOWN
THEN THEN THEN DROP ;
─────────────────────────────────────
提示
將具有同樣權數（weight）的布林常數值合併。
─────────────────────────────────────
許多雙巢狀的『如果 然後』結構，可以在做決定前，先利用邏輯操作元把旗標合併，來 達到簡化的目地。下面是一個雙巢狀的測試：
: ?找樂子 星期六? 如果
工作 完成了? 如果 去宴會 然後 然後 ;
這個例子中使用了巢狀的『如果』，在出去找樂子前，先確定是星期六，並且工作已做完 了。換另外一種方法，讓我們先將條件"邏輯地"合併起來，然後只做一個決定：
: ?找樂子 星期六? 工作 完成了? 而且 如果 去宴會 然後 ;
這樣簡單多了，並且也較有可讀性。 邏輯上"OR"的狀況，如果使用多個『IF THEN』來實現，會更難看：
: ?RISE PHONE RINGS? IF UP GET THEN
ALARM-CLOCK RINGS? IF UP GET THEN ;
寫成下面這樣，可能會比較好些：
: ?RISE PHONE RINGS? ALARM RINGS? OR IF UP GET THEN ;
這個規則的例外之一是，當有些條件的檢查太花費時間，而造成執行速度的損失過大時。 我們可以寫成
: ?炒麵 豆芽? 炒麵 食譜? AND IF 炒麵 準備 THEN ;
但是，假設我們需要花費很長的時間來搜尋食譜的檔案，才能知道炒麵裡需要哪些其它的 配料，很明顯的，如果我們已經沒有豆芽，就根本沒必要搜尋。所以，寫成下面的形式 比較有效率：
: ?炒麵 豆芽? IF 炒麵 食譜? IF 炒麵 準備 THEN THEN ;
如果沒有豆芽，我們就不需要檢查食譜。
另一種例外是：如果有任何條件可能是"不為真"的情況。那麼，若能先消除這個條件 ，你就不需要再測試其它的條件了。
─────────────────────────────────────
提示
在多種條件中，當各條件（在相似性或計算時間上）的輕重權數不相同的時候，巢狀 條件的做法是，將最不可能為真的、或最容易計算的，放在最外層。
─────────────────────────────────────
在"OR"的結構中，以這種方法來改進性能，會困難些。例如，在定義裡
: ?RISE PHONE RINGS? ALARM RINGS? OR IF UP GET THEN ;
我們測試電話和鬧鐘，只要其中一個響了，我們就起來。現在假設鬧鐘的響聲比較不容 易測試，我們可以寫成
: ?RISE PHONE RINGS? IF UP GET ELSE
ALARM-CLOCK RINGS? IF UP GET THEN THEN ;
如果第一個條件為真，我們就不必浪費時間評估第二個。反正我們要起來接電話。 『UP
GET』重複出現是很難看，比用『OR』的可讀性還要差，但有時還是非用不可。
控制結構的選擇
─────────────────────────────────────
提示
最漂亮的程式碼是最能貼切解決問題的。控制結構的選擇以最能配合問題的控制流程 為原則。
─────────────────────────────────────
狀況敘述（Case statement）
有一類特殊問題是：從幾種可能的執行路徑中，依照一個數值引數，從中選擇一種來執 行。例如，若我們要字『.SUIT』能由一個代表樸克牌花色的數值0到3，印出這個花色 的名稱。我們可以使用巢狀的 IF ELSE THEN 結構，像這樣：
: .SUIT ( suit -- )
DUP 0= IF ." HEART " ELSE
DUP 1= IF ." SPADES " ELSE
DUP 2= IF ." DIAMONDS " ELSE
." CLUBS "
THEN THEN THEN DROP ;
但若能使用"狀況敘述"，就可以更優雅的解決這個問題。下面是使用"Eacker狀況敘述" 的格式所重寫的定義。（它是以提出這個方法的Charles E. Eacker博士所命名的[1]）。
: .SUIT ( suit -- )
CASE
0 OF ." HEARTS " ENDOF
1 OF ." SPADES " ENDOF
2 OF ." DIAMONDS " ENDOF
3 OF ." CLUBS " ENDOF ENDCASE ;
這個狀況敘述的價值在於可讀性及可寫性。它在記憶體的使用和執行速度上，並沒 有效率上的改善。實際上，狀況敘述的編譯和巢狀的 IF THEN
編碼大致相同。狀況敘述 是編譯時區中因子分解（compile-time factoring）的一個好例子。
符式系統都必需內建有這種"狀況敘述"嗎？這倒是有爭議的。問題在兩方面。第一，
實際上需要這種狀況敘述的例子很少，少到我們會懷疑它存在的價值。如果只有少數的情 況，採用巢狀的 IF ELSE THEN
結構，雖然可讀性較差，但同樣可以做到。如果出現的次 數很多，一個判斷表（decision table）可能更具有彈性。
第二，許多與狀況有關的問題，並不特別適用於狀況結構。Eacker的狀況敘述是假
設：你要測試一個與堆疊上的數值相等的狀況。在『.SUIT』的例子裡，我們要測試的是
由0到3的連續整數。在這種情形下，經由引數去計算出一個偏移值（offset），並直接跳 到正確的程式碼上，會比較有效率。
在本章稍後的小小編輯器的例子裡，我們不只有一個次元，而是有兩次元的可能性， 這時，狀況敘述也無法適用。 我個人認為，狀況敘述是對於已經被帶入歧途的問題
--企圖以演算法來表達一種可 以使用判斷表很恰當的描述出來的問題-- 的另一種優雅的解決辦法。
狀況敘述，當能派上用場的時侯，應該是應用程式的一部份，而不該是系統的一部份 。
迴路結構（Looping structure）
正確的迴路結構可以消除額外的條件（conditionals）。
───────────────────────────────────────
Moore的說明：
在很多情況，條件判斷被用來跳出一個迴路。但是，如果一個迴路有許多出口，這種 特別的用法就能夠避免。 這是個仍在討論中的話題，因為多重的 WHILE
結構已經在polyFORTH系統裡出現， 可是還沒有被符式83標準採用。其實，在同一個 REPEAT 裡，定義多重的 WHILE 是一件很簡單的事。
而且，FORTH Inc.的Dean Sanderson發明了一種新的結構，可以在一個 DO LOOP
裡引進兩個出口。這種結構只需用到很少的判斷。我經常先在堆疊上留下一個"真" 旗標，如果我提早離開迴路，就改變旗標來表示這點。稍後，我再用一個 IF 來
看看我是否提前離開了迴路，這種方法實在很笨。 一但你做了一個判斷，就不應該再做它一次。如果迴路的結構被設計的很恰當，
你就不需要記住你是從那裡來的，因此，也就不需要跟在後面的那些條件判斷了。 這種方法還不是很流行，因為它還沒有被結構化。或者說，它的結構還不夠精密。
它的價值在於，你可以得到較簡單的程式而不必付出代價。
───────────────────────────────────────
不錯，這是個討論中的話題。以它目前的寫法來看，建議採用它做為新的迴路結構，為時 尚早。你可以查看你系統的使用手冊，看看它是否提供了一些優良的迴路結構。或者， 依你應用上的需要，考慮加進自己的條件結構。在符式裡，這並非一件難事。 我甚至也還不確定，使用這種多出口的方式，是否違反結構化程式的原則。在一個 BEGIN WHILE REPEAT 的迴路裡，使用多個 WHILE，所有的出口都將你帶到一個共同的 "繼續"點：即 REPEAT。但是在Sanderson的結構中，你可以繞過迴路的終點，直接跳 出迴路，到 ELSE "繼續"。所以它有兩個可能的"繼續"點。 我們可以說這種方法"不夠結構化"。但是，這個定義一定會從分號離開，並且回 到呼叫它的字內。從模組只有一個入口和一個出口的觀點來看，它仍是良好的結構化。 當你要執行一段特定的程式碼，而不想貿然地離開迴路，這種方法似乎是一種最自然 的可用結構。(稍後一節"使用結構化的出口"，我們可以看到一個例子。)
─────────────────────────────────────
提示
偏好"計次(count)"（定迴路），少用"終結符號(terminators)"（不定迴路）。
─────────────────────────────────────
符式是以"在第一個字元處存入字串長度"的方式來處理一個字串。這種方式使字串較容易 被顯示、搬移、或做任何事。當地址和長度都被放在堆疊上時，TYPE 的定義就能寫成：
: TYPE ( a # --) OVER + SWAP DO I C@ EMIT LOOP ;
（雖然 TYPE 實在是應該以組合語言來定義的。） 這個定義並沒有明顯的使用條件敘述。實際上，是 LOOP 將條件隱藏了，因為它在 每次迴路時，都會檢查索引值，如果還沒有到達上限，就回到 DO 再來。 如果使用分界符號（delimiter），像是ASCII中的"null"，則此定義必需寫成：
: TYPE ( a -- ) BEGIN DUP C@ ?DUP WHILE EMIT 1+ REPEAT DROP ;
每次經過迴路時，都需要再做一次額外的判斷。（ WHILE 是一個條件操作元。） 注意：從最佳化的觀點來看，這個解決方法裡，使用『?DUP』的代價很高，因為它 本身就包含了一個額外的判斷。一個執行的較快的定義是：
: TYPE ( a -- ) BEGIN DUP C@ DUP WHILE EMIT 1+ REPEAT 2DROP ;
在83年的標準裡的『INTERPRET』使用了這個原理，現在它接受一個計數，而不再去尋找 一個終結符號。
另一種做法是，使用一種最容易將結構連結（link）起來的資料結構。每一個記錄
都指著下一個（或前一個）記錄。串鏈的最後一個（或第一個）記錄可以在它的連結欄位 （link field）內填入一個零來表示。
如果你有一個連結欄位，你無論如何總是要將它的內容取出的。你或許同時也要測 試它是否為零。你不必保有一個計數來記錄它有幾個。（這種技術被使用在符式詞典上，
用來建構一個連結的列表。）如果你使用"將計數值遞減以決定是否要終止"的做法， 你只是替自己找更多的工作罷了。
計算結果
─────────────────────────────────────
提示 不要判斷，要計算。
─────────────────────────────────────
在很多時候，條件控制結構被誤用在一些情況中，其中，輸出上的差異只是由於數值上 的不同所造成。如果處理中涉及到數值，我們就可以用計算的。（參閱第四章，"計算 vs. 資料結構 vs. 邏輯"一節。）
─────────────────────────────────────
提示 將"布林值"視同"複合數值"（hybrid
value）一樣的使用。
─────────────────────────────────────
這是前一個提示「不要判斷，要計算」的自然結果。它的重點是，在電腦內部以數值所 表示的布林值，可以被很有效地用來影響數目的決定。這裡有一個在許多符式系統中 都可見到的例子：
: S>D ( n -- d ) \ sign extend s to d
DUP 0< IF -1 ELSE 0 THEN ;
（這個定義是用來將一個單長度的數值轉變成雙長度。雙長度的整數是以堆疊裡的兩個 元素來表示，高位部份（high-order part）在上方。要將一個正值的單整數轉變成 雙長度，祗要在堆疊上放一個零，代表它的高位部份即可。但是轉變一個負數為雙長度 ，則需要做"符號延伸"：也就是，高位部份必需都是1。） 上面的定義會先測試單長度數值是否為負值。如果是，它就將 -1堆入堆疊；否則 就堆入一個0。 但是注意，它的結果只是純算術的，並末涉及程序上的變化。我們可以利用這個特 性，從布林值本身獲得益處：
: S>D ( n -- d ) \ sign extend s to d
DUP 0< ;
這個版本也是將 -1 或 0 堆入堆疊，但卻不在判斷上浪費一點時間。 （在1983年之前的系統，定義可以是：
: S>D ( n -- d ) \ sign extend s to d
DUP 0< NEGATIVE ;
參看附錄C） 我們可以利用"複合數值"做更多的事。
─────────────────────────────────────
提示 若要以數值的結果來影響判斷，就使用 AND。
─────────────────────────────────────
在產生"0"或非零值"n"的判斷裡，傳統的片語
( ? ) IF n ELSE 0 THEN
等於下面較簡單的敘述
( ? ) n AND
又一次，訣竅是在： "真"旗標在1983年的符式系統裡是以 -1 (每個位元都是1) 表示。 將"n"與一個旗標做 AND，將產生"n"（所有的位元都不受影響），或"0"（所有的位元都 被清除為0）。 以一個例子來澄清這個觀點：
( ? ) IF 200 ELSE 0 THEN
它與下個指令是一樣的
( ? ) 200 AND
看一看這個例子：
n a b < IF 45 + THEN
把"n加45"或者不加的片語，是依a和b的相對大小所決定的。因為「加45或不加」與「加 45或加零」是一樣的，兩種結果的差異是純數值的。所以我們能不做判斷，只計算：
n a b < 45 AND +
───────────────────────────────────────
Moore的說明：
『45 AND』是比 IF 快，當然比較好。也比較簡單。如果你養成習慣，對從一個 數目計算得到另一個數目時，都去注意它。那麼，通常你都能夠以對邏輯值做算術 運算的方式，得到相同而又比較清楚的結果。 我不知道你叫它什麼。它還沒有名字；這只是以"邏輯值"來進行算術運算。但是它非 常有價值，而且總有一天，布林代數和算數的算式都將會用到它。 在一些書中，你經常可以看到很多分段式線性驅近法（piece-wise linear approxi -mations）的算式，可是它們在表達上都並不很清晰。下面是兩個例子：
x = 0 for t < 0
x = 1 for t ?0
這兩個式子與下一個相同
t 0< 1 AND
它可以用一句話就表示清楚，而不必使用分段的方式。
───────────────────────────────────────
我稱這些旗標是"複合數值"，因為它們是布林值（真假值）以資料（數值）的方式被使用 著。我不知道還有什麼其它的名字可以稱呼它。 如果我們能將兩種結果之間的差值分解出來，就可以省略 ELSE 的部份。例如：
: STEPPERS 'TESTING? @ IF 151 ELSE 150 THEN LOAD ;
可以簡化為
: STEPPERS 150 'TESTING? @ 1 AND + LOAD ;
這種方法在此處之所以可行，是因為我們是要載入第150冪，或者，當在測試的時候， 載入它的下一冪。
取巧（Tricks）上的注意
這類方法通常被冠上"取巧"之名。在大型電腦工業裡，"取巧"有個壞名聲。 取巧，簡單的說，就是利用某一種運作上的特性。在工程應用裡，"取巧"是被廣 為使用的。Chimneys利用熱升冷降的事實消除了煙霧。汽車輪胎利用了重力產生的磨擦 。算數邏輯單元（Arthmetic Logic Units）利用"減一個數目恰等於加上它的2的補數" 的這個事實來做運算。 這種取巧可以使設計變的更簡單和更有效率。只要它所假設的前題一直為真，它就 能夠發揮功能。 如果取巧的結果必需依靠其它經常變動的事項，或者它所依靠的事項沒有被資訊隱藏 的做法所保護，那麼，使用取巧就會變的很危險。 並且，當它所根據的假設不容易被瞭解，或沒有被解釋清楚，則這些取巧會變得很難 閱讀。在將條件以 AND 代換的例子裡，一但這種技巧變成每一個程式設計師詞典的一部 份時，程式碼將會變得比較容易閱讀。在一個特定應用中的一個特定的取巧，例如利用到 資料在一個表裡的順序關係，那麼，這個取巧所用到的假設，就必需被清楚地說明在程式 的文件中。
─────────────────────────────────────
提示 使用 MIN 和 MAX 來作裁剪（clipping）。
─────────────────────────────────────
假設我們要遞減變數 VALUE 的內容，但是不要使它小於零：
-1 VALUE +! VALUE @ -1 = IF 0 VALUE ! THEN
寫成這樣會更簡單：
VALUE @ 1- 0 MAX VALUE !
這個例子裡，"條件"被分解到字 MAX 裡。
使用判斷表
─────────────────────────────────────
提示 使用判斷表。
─────────────────────────────────────
我們在第二章介紹過它。判斷表是一種包含資料（資料表）或功能地址（功能表）的結構
，依任意的次元來安排。每一次元代表問題的一個特定面的所有可能的、互斥的狀態。在
每一次元為"真"狀態的交集處，存放著所期望的元素：一項資料或一個要被執行的功能。 當問題有多個次元時，判斷表很明顯地是一種比條件結構更好的選擇。
單次元的資料表（One Dimemsional Data Table）
這裡是一個簡單的單次元資料表的例子。我們的應用裡有一個稱為 FREEWAY? 的旗標， 當我們參考到的是快速道路時，它就是真。參考的若是市區道路時，它就是假。 讓我們定義出 SPEED-LIMIT 這個字，它會依目前的狀況，送回道路的速度限制。使 用 IF THEN ，我們能寫出：
: SPEED-LIMIT ( -- speed-limit )
'FREEWAY? @ IF 55 ELSE 25 THEN ;
我們可以使用一個複合數值和 AND 以省略 IF THEN
: SPEED-LIMIT 25 'FREEWAY? @ 30 AND + ;
但是這個方法並不符合問題的觀念上的模型，所以它並不容易閱讀。 讓我們試試資料表。這是一個單次元的表，只有兩個元素，沒什麼東西：
CREATE LIMITS 25 , 55 ,
字 SPEED-LIMIT? 現在必需使用布林值來獲得表中的資料：
: SPEED-LIMIT ( -- speed-limit )
LIMITS 'FREEWAY? @ 2 AND + @ ;
比起 IF THEN 的方法來，我們有沒有得到任何好處？恐怕沒有，因為這個問題太簡單。 然而，我們所做的是；從"資料本身"分解出"判斷的程序"。當我們有一組以上的 資料與同一個判斷有關時，這種方法就會顯的較有效率。假設我們也有
CREATE #LANES 4 , 10 ,
代表一條市區道路和一條快速道路的巷道數目。我們可以使用相同的程式碼，來計算 目前巷道的數目：
: #LANES? ( -- #lanes )
#LANES 'FREEWAY? @ 2 AND + @ ;
使用分解因子的技術，我們能將它簡化成：
: ROAD ( for-freeway for-city -- ) CREATE , ,
DOES> ( -- data ) 'FREEWAY? @ 2 AND + @ ;
55 25 ROAD SPEED-LIMIT
10 4 ROAD #LANES?
"單次元資料表"的另一個例子是"超級字串"（參看Starting FORTH 的第十章）。
二次元資料表
第二章裡，我們介紹了一個電話費率的問題。圖8-4是這個問題的一種解決方法， 它使用了二次元的資料結構。 在這個問題裡，資料表的每一次元都是由三個互斥的狀態所組成。所以，一個簡單的 布林值（真／假）並不合適。這個問題的每一次元都以不同的方法來實現。 依一天中的時段所決定的費率表，被當成是一個地址而儲存著，代表三種費率結 構副表中的一個。我們可以說
FULL RATE !
或
LOWER RATE !
等等。
圖8-4. 電話費率問題的一個解決方法
\ ~FBBB1;電話費率
CREATE FULL 30 , 20 , 12 ,
CREATE LOWER 22 , 15 , 10 ,
CREATE LOWEST 12 , 9 , 6 ,
VARIABLE RATE \ ~FBBB1;依一天裡的時段而指在 FULL、LOWER ~FBBB1;或~I; LOWEST
FULL RATE ! \ ~FBBB1;一個例子
: CHARGE ( 0 -- ) CREATE ,
DOES> ( -- rate ) @ RATE @ + @ ;
0 CHARGE 1MINUTE \ ~FBBB1;第一分鐘的收費
2 CHARGE +MINUTE \ ~FBBB1;後續每分鐘的費率
4 CHARGE /MILES \ ~FBBB1;每分鐘每百哩的費率
VARIABLE OPERATOR? \ ~FBBB1;如果經由接線生協助, 它的值是90 ; ~FBBB1;否則是0
VARIABLE #MILES \ ~FBBB1;通話距離的百哩數~I;
: ?ASSISTANCE ( ~FBBB1;第一分鐘的連線費用 -- 加上接線生的費用~I; )
OPERATOR? @ + ;
: MILEAGE ( -- charge ) #MILES @ /MILES * ;
: FIRST ( -- charge ) 1MINITE ?ASSISTANCE MILEAGE + ;
: ADDITIONAL ( -- charge ) +MINUTES MILEAGE + ;
: TOTAL ( #minutes -- total charge ) 1- ADDITIONAL * FIRST + ;
目前的收費，不論是第一分鐘、以後的每一分鐘、或每英哩，在表內都是以一個位移值來表示（0, 2, 或 4）。
最佳化要注意的地方：我們以三個單次元表來實現一個二次元表，每個單次元表都經由 RATE 所指出。這種方法省略了二維結構所必需執行的乘法。在某些狀況下，乘法可能會比較慢。
二維判斷表
讓我們回到第三章的小小編輯器，以它為例子來說明二維判斷表的使用。
圖8-5 小小編輯器的應用
\ ~FBBB1;小小編輯器
2 CONSTANT NORMAL \ offset in FUNCTIONS
4 CONSTANT INSERTING \ "
6 CONSTANT /KEY \ byte in table for each key
VARIABLE MODE# \ current offset into table
NORMAL MODE# !
: INSERT-OFF NORMAL MODE# ! ;
: INSERT-ON INSERTING MODE# ! ;
VARIABLE ESCAPE? \ t=time-to-leave-loop
: ESCAPE TRUE ESCAPE? ! ;
\ ~FBBB1;建造功能表~I;
: IS ' , ; \ function ( -- ) ( for '83 standard )
CREATE FUNCTIONS
\ keys normal mode insert mode
4 , ( ctl-D ) IS DELETE IS INSERT-OFF
9 , ( ctl-I ) IS INSERT-ON IS INSERT-OFF
8 , ( backspace) IS BACKWARD IS INSERT<
60 , ( left arrow) IS BACKWARD IS INSERT-OFF
62 , ( right arrow) IS FORWARD IS INSERT-OFF
27 , ( return ) IS ESCAPE IS INSERT-OFF
0 , ( no match ) IS OVERWRITE IS INSERT
HERE /KEY - CONSTANT 'NOMATCH \ adr of no-match key
VARIABLE MATCHED
: 'FUNCTION ( key -- adr-of-match ) 'NOMATCH MATCHED !
'NOMATCH FUNCTIONS DO DUP I @ = IF
I MATCHED ! LEAVE THEN /KEY +LOOP DROP
MATCHED @ ;
: ACTION ( key -- ) 'FUNCTION MODE# @ + @ EXECUTE ;
: GO FALSE ESCAPE? ! BEGIN KEY ACTION ESCAPE? @ UNTIL ;
圖8-5裡，我們構建了一個表，它儲存著鍵被按下時所要執行的功能。它的效果與"狀況敘述"相似，不同的是它有兩種模式，正常模式和插入模式。每個鍵依目前所在的模式，有著不同的行為。
首先要實現的是改變模式的部份。如果呼叫
NORMAL MODE# !
就進入"正常模式"中。
INSERTING MODE# !
就進入"插入模式"。
接下來是建造 FUNCTIONS 的功能表。此表是由按鍵的ASCII值、跟著正常模式的鍵功能的地址、再跟著插入模式鍵功能的地址所組成。然後是第二個鍵及下一對功能的地址，...依此類推。
在最後，字『'FUNCTION』取得一個按鍵，並搜尋 FUNCTIONS 表中相合的值，然後傳回那個元素的地址（我們先預設變數 MATCHED 指著表的最後一列，也就是當任何其它鍵被按下時，所要執行的功能。）
字『ACTION』呼叫『'FUNCTION』，然後加上變數 MODE# 的內容。因為 MODE# 存放著0, 2或 4，加上這個偏移值，就能使我們指著表中所要執行的常式的地址。有了這個地址之後，一個簡單的敘述
@ EXECUTE
就能執行這個常式。
在FIG符式裡，『IS』的定義要改為：
: IS [COMPILE] ' CFA , ;
在79標準的符式裡，則定義為：
: IS [COMPILE] ' , ;
我們在功能表底部的那個定義裡，也使用了"編譯時區中的非重複性"的原則：
HERE /KEY - CONSTANT 'NOMATCH \ adr of no-match key
就在那功能表的最後一行，我們製作了一個常數。（當我們叫用 HERE 的時刻，它指著表中下一個可用的儲存地址。在6個字元之前，也就是最後一行的起始處。）現在，我們有兩個字：
FUNCTIONS ( adr of beginning of function table )
'NOMATCH ( adr of "no-match" row; these are the routines for
any key not in the table )
我們用這些名字來提供傳送給 DO 的地址：
'NOMATCH FUNCTION DO
以設定一個迴路，從表格中的第一行做到最後一行。我們不必知道表中有多少行。我們甚至可以取消或增加一行，而不必改變任何程式碼，即使是用來搜尋這個表的碼也不必改變。
常數『/KEY』也有類似的功能，它將每欄位所佔有的字元數的資訊隱藏在表裡。
不幸的是，『'FUNTION』在表中取得資料的方法是個不太好的設計：它用了一個本地變數以簡化對堆疊的控制。一種簡單又不必使用本地變數的解決方法是：
: 'FUNCTION ( key -- adr-of-match )
'NOMATCH SWAP 'NOMATCH FUNCTIONS DO DUP
I @ = IF SWAP DROP I SWAP LEAVE THEN
/KEY +LOOP DROP ;
（在本章稍後的"使用結構化的出口"部份，我們將提供另一種解決辦法。）
為了增加速度的判斷表
我們剛才說過，如果你能計算出答案，而不用到表裡去尋找它，你就該這樣做。一個 例外是，當執行速度的要求比起因為使用表格而引進的複雜性更為重要的時候。 這裡是一個計算2的次方的例子。
CREATE TWOS
1 C, 2 C, 4 C, 8 C, 16 C, 32 C,
: 2** ( n -- 2-to-the-n ) TWOS + C@ ;
我們不必以2乘自己"n"次來計算答案，答案都事先被計算好，並存在表裡。我們可以 用簡單的加法得到表中的地址，以取得答案。 一般說來，加法比乘法快很多。
───────────────────────────────────────
Moore提供的另一個例子：
如果你要計算一個三角函數，像是為了圖形的顯示，你不需要太好的解像度。一個 7位元的三角函數也許就足夠了。尋找一個有128個成員的表，會比你所能想到的任何
其他方法都要快。對於低頻率的功能函數的計算來說，判斷表非常好用。 但是如果你必需求得中間項（interpolate），你終究是要計算一個函數的。也許
最好還是去計算出一個功能稍微複雜些的函數，並且避免使用查表的方式。
───────────────────────────────────────
重新設計
─────────────────────────────────────
提示 一個底層的改變，可以節省十個頂層的判斷。
─────────────────────────────────────
在本章開始時對Moore所做的訪問中，他提到，如果經由重新設計，用兩個字來取代一 個字，那麼一個應用程式中大部份的條件測試，就可以被省略；「你可以說 GO 或者說 PRETEND」。 改變你的環境的前後關係，以便執行一個簡單而一致的演算法，要比保持環境固定 不變，而從幾個演算法之中做選擇要簡單的多。 請回憶第一章中蘋果的例子。它最初被定義為變數；在整個應用中它被參考到很多 次，例如使蘋果的數目增加（送貨車來時），使數目減少（蘋果賣掉時），及檢查目前的 數量（做庫存控制時）。 當必需加上處理第二種蘋果時，使用錯誤的方法將會增加所有運輸／銷售／庫存用字 的複雜度。正確的方法就是我們使用的那種："在最底部"增加複雜度；也就是蘋果本身。 這個理論可以有很多方法來實現。在第七章（"狀態表"一節），我們經由狀態表來執 行字 WORKING 和 PRETENDING，它們改變一組變數的意義。本章稍後，我們將以向量式的 執行方式來定義 VISIBLE 和 INVISIBLE，以改變『TYPE'』，『EMIT'』，『SPACES'』和 『CR'』的意義，其結果是所有使用到它們的程式碼，都能很容易地被改變。
─────────────────────────────────────
提示 不要測試那些不可能發生的事。
─────────────────────────────────────
許多現代的程式設計師都是"錯誤檢查"(error-checking)的上癮者。 不需要在一個功能中，檢查從系統裡另外一個元件所傳送過來的引數。"呼叫程式"有 責任不讓"被叫用的元件"超載。
─────────────────────────────────────
提示 重新檢討演算法。
─────────────────────────────────────
───────────────────────────────────────
Moore的解釋：
有很多條件是因為對問題的怪異想法所產生的。在伺服控制的理論裡，很多人認為 ，"伺服演算法"在距離較遠時，應該與接近時有所不同。在很遠時，你是在迴轉模式
裡；接近目標時，你是在減速模式；非常接近時，你卻是在獵取（hunt）模式。你 必需測試你有多遠，以便找到正確的演算法來運用。
我發展出一種非線性的伺服控制演算法，可以做全距離的控制。這種方法消除了從 一種模式到另一種模式的轉換空隙。它省略了原先為了測知使用何種演算法所必需
做的判斷。它也消除了你必需對轉換點所做的判斷。當然，你因此有一個簡單多了 的程式，它只用一種演算法，而不是原來的三個。
───────────────────────────────────────
─────────────────────────────────────
提示 避免對特殊處理的需求。
─────────────────────────────────────
有一個我們在本書稍前提到的例子：如果你能讓使用者沒有麻煩，你就不必一直查看 使用者是否有麻煩。
───────────────────────────────────────
Moore解釋：
寫組譯器是另一個好例子。經常，一個操作碼（opcode）可能沒有和它相關的暫存器
。但是如果假設它有一個暫存器，像是暫存器0，程式碼就可以被簡化。在算術運 算裡，引進原本不需存在的位元圖樣，可以簡化解決的方法。你可以直接用0來替
換，而繼續做這個算術運算，以代替你原來所要做的 --測試0的情況以決定是否要 跳過這個運算。
這是另一個"忽略不計"的例子。如果你真的不在乎，那麼就隨便給它一個虛值，無論 如何，用它就是了。
───────────────────────────────────────
當你遇到一個特殊狀況時，試著找出一個能將特殊狀況變成一般狀況的演算法。
─────────────────────────────────────
提示 使用元件的性質。
─────────────────────────────────────
一個設計良好的元件，不論是硬體或軟體，可以讓你以一種清晰而又有效率的方式執 行一個詞集。老式的Epson MX-80印表機（現在已經廢除了）裡的字形組將這種觀點詮 釋的很好。圖8-6顯示的是ASCII碼從160到223的圖形字元。
圖8-6 Epson MX-80的圖形字組
每一個圖形字元由六個小方格所組成，它可以是塗黑或留白。假設在我們的應用裡，我們 要使用這些圖形來製作一個設計。對於每一個圖形，我們很清楚這六個位置的每一個是 什麼 --現在，我們必需為印表機產生相對應的ASCII碼。 只要稍為看一下，你就知道這是一個非常理性的圖案。假設我們有一個6字元寬的表 ，其中每一個字元代表著圖形裡的一個圖素：
┌──┬──┐
圖素 │ 0 │ 1 │
├──┼──┤
│ 2 │ 3 │
├──┼──┤
│ 4 │ 5 │
└──┴──┘
並且假設，如果圖素"on"，則該字元值是 FF，"off"則為0。現在你可以看一下，計算 這些圖形碼的程式有多麼小：
CREATE PIXELS 6 ALLOT
: PIXEL ( i -- a ) PIXELS + ;
: CHARACTER ( -- graphics_character )
160 6 0 DO I PIXEL C@ I 2** AND + LOOP ;
(稍後我們會介紹 2** ) 在 CHARACTER 的定義裡並沒有判斷。圖形碼是由簡單的計算所得到的。 注意：如果要使用同一個演算法，來轉換一組較大圖格（large grid）裡相鄰的六 個圖素時，只要重新定義 PIXEL 即可。這是一個加上反向間接（adding indirection backwards）的例子，並且也是一個良好分解的例子。 不幸的是，這些"外部元件"並不全都是被設計的很好的。例如，IBM的個人電腦在它 的視頻顯示中，使用了一個相類似的設計來做出圖形字元，但是它在ASCII數值和圖素之 間，並沒有明顯的對應關係。唯一產生ASCII數值的方法，就祗有使用查表的方式。
───────────────────────────────────────
Moore的說明：
如果你想尋找的是一種使用最少的運算子來表示操作碼（op-codes）的好方法，
68000組譯器會是另一個令人心碎的例子。從所有的跡像看來，實在沒有一種好的
解決辦法。設計68000的人，顯然沒有把組譯器放在心上。他們其實可以把事情弄 的簡單些，而不必付出什麼代價。
───────────────────────────────────────
以這種方式來使用一個元件的性質，你的程式碼就會變成依賴這些性質，因而也會依賴
元件本身。這是可接受的，因為所有依賴性的程式碼都被限制在這一個詞集中，如果有 必要，它們也能很容易地被修改。
使用結構化的出口（Using Structured Exits）
───────────────────────────────────────
提示 使用結構化的出口。
─────────────────────────────────────
在分解因子一章中，我們說明了使用這種技巧將控制結構分解出來的可能性：
: CONDITIONALLY A B OR C AND IF NOT R> DROP THEN ;
: ACTIVE CONDITIONALLY TUMBLE JUGGLE JUMP ;
: LAZY CONDITIONALLY SIT EAT SLEEP ;
符式讓我們能夠直接操縱返回堆疊，以改變控制流程。（如果你懷疑，請參閱〈Starting FORTH〉第九章。）草率的使用這種技巧，會造成程式碼的非結構化。但是，如果能嚴謹 的使用結構化出口，卻可以實質的簡化程式碼，並改善程式的可讀性和可維護性。
───────────────────────────────────────
Moore說：
我越來越喜歡使用『R>
DROP』來改變控制的流程。它與『ABORT"』（放棄）的效果 類似，而後者卻有一個『IF THEN』在裡面。雖然如此，整個系統中就祗有這一個 『IF
THEN』，並不是每個錯誤處理中都出現。 我或許要『放棄』，或許不放棄。如果我不放棄，我就繼續下去。如果我放棄，就不
必要還沿著所有的路線走一遍。我會另走一條捷徑。 另一個方法是，讓程式中其它的碼來負責檢查錯誤是否曾經發生過。但這樣是很不方 便的。
───────────────────────────────────────
在特殊狀況下，"放棄路徑（abort route）"的使用，要比正常的控制流程的反應要好些 。『ABORT"』和『QUIT』提供了這種功能。 "結構化出口"擴充了這個觀念，允許立即停止目前的字的執行，而不必離開整個 應用程式。 不要將這個技巧與 GOTO 混淆，GOTO 是非常沒有結構性的。你可以用 GOTO 跳到 任何位置，不論是模組之內或之外。而使用此處的技巧，你只能跳到模組的固定出口 （分號處），並繼續執行呼叫它的字。 字『EXIT』會立即中止它所在的那個字的執行。片語『R> DROP』會使它所在的那個 字執行完畢後，中止呼叫者的繼續執行；效果一樣，但卻能使用在低一層的定義中。這裡 有一些這兩種方法的例子。 如果你有一個『IF ELSE THEN』的片語，THEN 之後沒有程式碼，像這樣：
... HUNGRY? IF EAT-IT ELSE FREEZE-IT THEN ;
你可以使用 EXIT 來省略 ELSE：
... HUNGRY? IF EAT-IT EXIT THEN FREEZE-IT ;
（如果條件屬實，我們執行『EAT-IT』並跳出；『EXIT』的行為像是一個分號。如果條件 是假，我們跳到 THEN 並且執行『FREEZE-IT』。） 在這裡使用 EXIT 比較有效率，節省了兩個字元及額外的執行碼，但可讀性卻較 差些。
───────────────────────────────────────
Moore對這種技巧的價值和危險性的評斷：
特別是當條件變得很複雜的時候，能在程式中間跳出，而不必到最後符合了所有THEN 的條件時才跳出，真是一件很爽的事。在一個應用程式裡，我曾經有一個像這樣 的字：
: TESTING
SIMPLE 1CONDITION IF ... EXIT THEN
2CONDITION IF ... EXIT THEN
3CONDITION IF ... EXIT THEN ;
『SIMPLE』是用來處理簡單的狀況。『SIMPLE』的定義是以『R> DROP』片語做結束 。其它部份用來處理較複雜的情況。
它們當中的每一個都在同一點跳出，不必痛苦地去符合所有的 IF、ELSE、THEN 等等 的條件。到最後，如果沒有一個條件是符合的，就是一個錯誤狀況。
這個碼寫的很不好，因為它很難除錯。但是它卻反應出問題的本質。沒有其它更好的 辦法來處理它。『EXIT』和『R> DROP』至少還能使事情在掌握之中。
───────────────────────────────────────
程式設計師有時也使用 EXIT，跳出複雜的 BEGIN 迴路。或者我們也能在『DO LOOP』裡 使用類似的技巧，像是在本章稍前處，我們在「小小編輯器」所寫的『'FUNCTION』。在 這個字中，我們搜尋一系列的地址，查看是否有符合的情況。如果發現到一個，我們就 將它的地址傳回；如果找不到，我們就傳回功能表中最後一行的地址。 現在我們可以引入『LEAP』這個字（參看附錄C），它的功能與『EXIT』相似（它也 是模擬一個分號）。現在我們可以寫：
: 'FUNCTION ( key -- adr-of-match ) 'NOMATCH FUNCTIONS
DO DUP I @ = IF DROP I LEAP THEN /KEY +LOOP
DROP 'NOMATCH ;
如果我們找到一個相符的，我們就『LEAP』，不做『+LOOP』，但是要立刻做，並且在 堆疊上留下『I』（我們找到的地址）。如果沒有找到一個相符的，我們會經過迴路並 且執行
DROP 'NOMATCH
它拋棄所要尋找的鍵，並留下最後一行的地址！
如我們所見，"提前跳出"都有一個適當的時機，甚至在多出口和多"繼續"的情況下 ，都是如此。但這種使用『EXIT』和『R>
DROP』的方法，與最直接的結構化程式設計原 理，嚴格地說並不一致，使用時要特別小心。
例如，你或許會在定義開始時，在堆疊上擺上一個數值，它是要給定義結束時使用 的。過早的跳出會在堆疊上留下一個多餘的值。
玩弄返回堆疊就像玩火一樣。你可能被燒到。但是有了火，卻帶給人類很大的方便。
使用正確的時機
─────────────────────────────────────
提示 當你覺得必需做的時候，立刻採取行動，不要等。
─────────────────────────────────────
任何時刻，當你設定一個旗標時，就試著問自己為什麼要設定它。如果答案是「這樣稍後 我就能知道該這樣..這樣..的做」，就接著問你自己，是否現在就可以這樣做。一小點的 重新建構，可能會大大地簡化你的設計。
─────────────────────────────────────
提示 對於現在就可以編譯的東西，不必等到執行時再做。
─────────────────────────────────────
任何時候，若你能在編譯一個應用程式之前做出一個決定，立刻就做。 假設你有兩種版本的陣列：一個是在程式發展時為了防止錯誤發生，會檢查是否越界 （bounds）以做保護，另一個執行的較快，但是它在實際應用中卻沒有保護。 要將這兩種版本放在不同的冪中。當你編譯應用程式時，只載入你所需要的版本。 順便提一下，如果你照著這個建議去做，每次當載入的版本改變時，你可能要不勝其 煩的去編輯載入冪，以便能載入所要的版本。你其實可以換一種方式，寫一個在最後可以 丟掉不要的定義，讓它為你做判斷。例如（在另一節裡你已看過）：
: STEPPERS 150 'TESTING? @ 1 AND + LOAD ;
─────────────────────────────────────
提示 要去『複製』一個旗標，而不要再重建一個。
─────────────────────────────────────
有時你需要一個旗標，用來指示是否前面一些程式碼已經被呼叫過。下面的定義會留下 一個旗標，用來指示『DO-IT』是否已被執行：
: DID-I? ( -- t=I-did )
SHOULD-I? IF DO-IT TRUE ELSE FALSE THEN ;
它可以被簡化為：
: DID-I? ( -- t=I-did )
SHOULD-I? DUP IF DO-IT THEN ;
─────────────────────────────────────
提示 不要設定一個旗標，而要設定一個資料。
─────────────────────────────────────
如果設定旗標的唯一目的，是為了爾後某些程式碼可以在一個數目和另一個數目之間做 判斷，你最好將數目本身保留下來。 第六章"分解因子的準則"一節中"顏色"的例子，說明了這個觀點。 字『LIGHT』的目的是設定一個旗標，它指出我們是否要高亮度的位元被設定。雖然 我們可以寫出
: LIGHT TRUE 'LIGHT? ! ;
來設定旗標，以及
'LIGHT? @ IF 8 OR THEN ...
來使用這個旗標。但這種方法並不如直接將高亮度位元放在變數中來的簡單：
: LIGHT 8 'LIGHT? ! ;
並且簡化成
'LIGHT? @ OR ...
來使用它。
─────────────────────────────────────
提示 不要設定一個旗標，要設定一個功能。(向量)。
─────────────────────────────────────
這個提示和前一個類似，並且都存在著相同的限制。如果設定一個旗標的唯一目的是， 爾後某些程式碼可以在一個功能和另一個之間做判斷，你最好存下功能本身的地址。 例如，傳送一個文字到印字機的程式碼和直接將文字放到顯示器上的程式碼不一樣。 差勁的執行方法會定義成：
VARIABLE DEVICE ( 0=video | 1=printer )
: VIDEO FALSE DEVICE ! ;
: PRINTER TRUE DEVICE ! ;
: TYPE ( a # -- ) DEVICE @ IF
( ... code for printer ... ) ELSE
( ... code for video ... ) THEN ;
這種做法不好，因為每次你要輸出一個字串時，都要決定執行哪一種功能。 較好的實現方式是使用向量式的執行。例如：
DOER TYPE ( a # -- )
: VIDEO MAKE TYPE ( ... code for video ... ) ;
: PRINTER MAKE TYPE ( ... code for printer ... ) ;
這樣較好，因為『TYPE』不必決定要使用哪一段程式碼，它已經知道了。 （在一個多工系統中，印字機和監視器的工作，都有它自己的一個執行向量的拷貝 ，以便讓『TYPE』將它儲存在一個使用者變數中。） 上面的例子說明了這個提示的限制。在第二個版本中，我們並沒有簡單的方法能夠 知道目前的裝置是印字機或是顯示器。我們也許需要知道這點，以便能決定是否要清除螢 幕或者送一頁紙。我們用到了"狀態"的另一種用途，因而我們的提示也就不再適用了。 事實上，旗標的使用是允許"依賴狀態來操作"的最簡單的實現方式。但是在『TYPE』 的情況裡，我們關心的是速度。我們印字串的次數太頻繁，不允許浪費時間重複地做判斷 。最好的解決辦法是設定『TYPE』的功能，同時也設定一個旗標：
DOER TYPE
: VIDEO 0 DEVICE ! MAKE TYPE
( ... code for video ... ) ;
: PRINTER 1 DEVICE ! MAKE TYPE
( ... code for printer ... ) ;
於是，TYPE 知道該執行那一個程式碼，而另一個定義也能參考旗標『DEVICE』。 另一種可能是寫一個字，它能取得『TYPE』的參數（目前程式碼的指標），並將它 與 PRINTER 的執行地址相比較。如果它小於 PRINTER 的地址，我們便是在使用 VIDEO 的常式；否則，就是在使用 PRINTER 的常式。 如果狀態的改變包含了一小部份功能的改變，你仍然可以使用 DOER/MAKE。這裡是 三種記憶體移動的操作定義，它們可以一起被關掉。
DOER !' ( vectorable ! )
DOER CMOVE' ( vectorable CMOVE )
DOER FILL' ( vectorable FILL )
: STORING MAKE !' ! ;AND
MAKE CMOVE' CMOVE ;AND
MAKE FILL' FILL ;
: -STORING MAKE !' 2DROP ;AND
MAKE CMOVE' 2DROP DROP ;AND
MAKE FILL' 2DROP DROP ;
但是，如果有大量的功能需要被向量化，使用狀態表會比較好。 這個規則的結果引出了「結構化的出口掛勾（structured exit hook）」，它是一 個"DOER字"，被指向到去執行一個結構化的離開（EXIT）。
DOER 猶豫 ( the exit hook )
: 婚姻無效 猶豫 離婚登記 ;
( .... )
( ...在程式中很後面的地方: )
: 緩和 MAKE 猶豫 送花 R> DROP ;
開始時，『猶豫』並不做任何事。如果此時呼叫『婚姻無效』，就會上法院。如果 我們在『婚姻無效』之前做『緩和』，就會先送花，並清爽的跳到分號，甚至在我們 的另一半發覺這件事之前，就制止了那個法院傳票的送出。 這個方法特別適合當"取消的動作"必需被很後面才定義出的功能所執行的狀況（依 順序上的複雜度所拆解）。前面程式碼的複雜性增加的很有限，你只需要定義出掛勾， 然後在適當的時間呼叫它即可。
簡化
我保留這個的提示，將它放在最後，是因為它可以做為一個範例來說明簡化的優點。 當其它的提示著重在可維護性、效果、精簡等等時，這個提示卻是與滿意度有關的。
─────────────────────────────────────
提示 盡量避免將所有的旗標都保存在記憶體裡。
─────────────────────────────────────
一個在堆疊上的旗標，和一個在記憶體裡的旗標，有很大的不同。在堆疊上的旗標能夠 很容易被決定（以讀入硬體、計算、或任何其它方法），放到堆疊上，然後被控制 結構用掉。它的生命既短暫又不複雜。 但是若將旗標保存在記憶體裡，看看會發生什麼事。你除了有旗標本身之外，還 增加了旗標位置的這個複雜度。這個位置必需：
• 被製造出來 • 被初設（甚至是在有任何東西真正地改變之前） • 被重置（否則，若將一個旗標傳送到一個指令，該旗標會一直保留著目前的狀態）
因為在記憶體中的旗標是個變數，所以它們也是"不可再進入的"（not reentrant）。 會讓我們重新考慮是否真的需要一個旗標的例子之一，就是那個我們已經看過好多 次的"顏色"的例子。其中，我們假設最好的語法是：
LIGHT BLUE ( 淡 藍色 )
也就是形容詞 LIGHT 出現在顏色之前。這沒有問題。但是，記得執行那個版本的程式碼 嗎？ 請將它和下面這種方法的簡單性做個比較：
0 CONSTANT BLACK 1 CONSTANT BLUE 2 CONSTANT GREEN
3 CONSTANT CYAN 4 CONSTANT RED 5 CONSTANT MAGENTA
6 CONSTANT BROWN 7 CONSTANT GRAY
: LIGHT ( color -- color ) 8 OR ;
在這個版本裡，我們將語法反轉，所以我們現在說
BLUE LIGHT ~FBBB1;( 藍色 淡 )
我們先設定顏色，然後再去修飾它。 在完成後，我們消除了對一個變數的需求、讀取變數的程式碼、和更多的重置變數 的程式碼。並且，這個程式碼是如此的簡單，是不可能看不懂的。 當第一次寫這些指令時，我使用像口語的方式。『BLUE LIGHT』聽起來前後顛倒， 一點也不能接受。但那是在我和Chuck Moore談話之前。
───────────────────────────────────────
Moore的哲學很具說服性：
我要在「英文說的好」和「說的好」之間區別出來。其它語言，像西班牙語，形容詞 是跟在名詞之後的。我們應該不受「用來思考的語言是怎樣的」這種細節的約束。
它取決於你的意圖：要簡單，還是要像英文。英文並不是一種非常優越的語言，我們 用不著像奴隸一樣的跟著它。
───────────────────────────────────────
如果我要將這些處理顏色的字包裝起來，賣給繪圖藝術家使用，我可能會自找麻煩的 去製造一個旗標。但是對這些給我自己使用的字，如果我需要再寫它一遍，那我寧願 受Moore的影響，使用『BLUE LIGHT』的語法。
結語
將邏輯和條件當作是寫程式的重要結構單元，會導致程式過份的複雜，不容易維護， 和沒有效率的編碼。在本章裡，我們討論了幾種方法，以減少、最佳化、或消除不需要 的條件結構。 最後一點， 符式對條件的處理方式，是不太適用於其他大部份的現代語言上的。 事實上，日本根據它們的第五代電腦計劃，發展出一種稱為 PROLOG 的語言，即 PROgramming in LOGic，它是一種完全使用邏輯的語言。當我們深思下面的問題
To "IF" or not to "IF"
的時候，很有趣的，我們可以看到一個戰線的形成。 本書裡，我們介紹了軟體發展周期的前六個步驟，包含了軟體設計的哲理問題，和實現 可靠的、有效率的、可讀性高的軟體的實際考慮。 我們沒有討論到的是：程式的最佳化，確實性，除錯性，文件性，及計劃管理， 發展工具，組譯器，遞迴（recursion）的使用和誤用，多應用程式（multiprogrammed applications）的發展，或目標編譯（Target compilation）。 但那將是另外一個故事。
參考書籍
1. Charles Eaker，"Just in
Case" 符式 Dimensions II/3, p.37。
更進一步的考慮
你有一個字『CHOOSE』，它取一個引數"n"，並送回一個從0到n-1的任意數。其結果 永遠是正或零。你可以用 CHOOSE 來產生一個旗標；片語
2 CHOOSE
產生一個 0或 1的旗標（假或真）。 試著寫出一個片語，它能產生0到19（包含）之間，或 -20 到0之間的任意數。