The art of metaprogramming

閱讀以下三篇文章：

1. The art of metaprogramming, Part 1: Introduction to metaprogramming
2. The art of metaprogramming, Part 2: Metaprogramming using Scheme
3. The art of metaprogramming, Part 3: Enterprise metaprogramming

內有對 macro 極佳的說明。

Scratch 和 Google App Inventor

一種為小孩子設計的語言：Scratch。

這樣的語言，及發展環境，也是我的夢。

Google 的 App Inventor 也提供了類似 Scratch 的開發環境，但是內部使用的語言是 Scheme。

Kawa

以 Java 寫成的 Scheme，可以在 JVM 上執行。因此我忍不住將它和 plt-scheme 及 rhino 比較，以瞭解它的優劣定位。

相較於 rhino：

1. 同樣可在 JVM 上執行。
2. 援用 java 的 class 時，沒 rhino 那麼方便，必須定義要使用的 method，若使用某個 method 眾多的類別如 JOGL 時，會帶來一些困擾。
3. 因為是 scheme，比 rhino 更適用於開發 Domain specific language (DSL)。

相較於 PLT-SCHEME

1. 可在 JVM 上執行，因此，可以和使用 rhino 的程式整合在一起，提供 rhino 欠缺的 DSL 能力。
2. 缺少 PLT-SCHEME 的龐大功能及其健康的社群。

Kawa 被用於 Google 的 App Inventor，被使用的原因就是因為 Scheme 的 DSL 能力。

依我的觀點，Scheme 的 DSL 能力最適合用在當 Domain specific language 尚未定型，正在成長時。

Functional Programming

使用 PLT Scheme 撰寫遊戲至今，我完完全全體會到 functional programming 的表達力。在我的程式中，現在到處是 map 及 lambda。而且，setter 的使用也減少許多。
不過，我寫遊戲的方式是有點瞎子摸象方式的，沒什麼事先的設計規劃。完全是玩玩改改。目前這樣做的進展很快。但能持續到何時，可維護性如何，我還沒有把握。

Chat and Wiki for Scheme.

台灣很少有和 Scheme 這種語言有關的資訊。既然我目前使用 Scheme 做為我開發遊戲的語言，我就將這部落格做為我提供 Scheme 相關資訊的平台。

由於需要，我搜尋是否有以Scheme實現的 wiki ，發現了以下網頁。

http://practical-scheme.net/

在網頁中有個 WiLiKi 從開發的歷史來看，這 Wiki 從 2001 年到 2009 都有開發的活動。因此我粗淺地斷定這作者不會放棄這個 Wiki 軟體的開發，因此值得信賴。

在這網頁中還有個 chat room 的軟體，這也讓我頗感興趣。

Continuation Web Server works great!

將原本以 javascript 及 Helma NG 寫成的遊戲程式以 PLT Scheme 改寫，使用 PLT Scheme 的 Web server，我發覺 Scheme 的 continuation 真的是撰寫動態網頁的利器。使用 javascript 時，點選遊戲中某個容器的物件，必須將這物件的 id 變成網頁上連結的參數，這樣點選物件時才能將這 id 回傳給 server，server 才知道點選的是哪一個物件。這也使得網頁的設計和 model 密不可分。但是使用 continuation 時這件工作就省下來了。在網頁上的連結對應的就是處理那物件的 continuation。我在撰寫這部分程式時根本就很少關心網頁要傳什麼資料給 server 的問題。

Continuation 實在太神奇了！

Continuation or not continuation

在瞭解了 Continutaion 在 Web development 的應用後，我以為 continuation 只適用於部份的Web程式。這時，就不得不覺得 PLT Scheme 的文件中對不使用 continuation 的 Web development 方法討論太少了。

以下的文章反應了我的想法，也提供了另一種以 PLT Scheme 撰寫 Web applications 的 tutorial：

• Pratical web programming with PLT Scheme

Model-View-Controller 及 Continuation

PLT Scheme Web Server 是一種 Continuation based Web Server。HTTP 的 stateless 特性使得某類網路應用程式難以撰寫。而 Continuation 可以解決這類的問題。

但是初次接觸 Continuation based Web Server 的我對這種程式的寫法不無疑問。在當初以 javascript 及 Helma NG 撰寫我的遊戲軟體時，我採用的是 page oriented 的撰寫方式，這樣的撰寫方式很自然地和 Model-View-Controller 的理念對應。但是當我以 Continuation 來撰寫時，還摸索不出如何做到 Model-View-Controller 的方法。

以我游戲中的一個場景為例。這場景秀出一段文字，之後給玩家三個選項，玩家點了選項後會跑到另一個場景，因此網頁上和這選項對應的連結必須指出將要到哪一個場景。如果使用 Continuation，產生 html 的 function (View) 必須知道這連結要執行哪一個 function (Controller)，以產生那個 function 的 continutaion。但這使得 View 必須知道 Controller。再者，如果那個被連結的 function 會使用到產生 html 的 function 的 local 資料或引數，則那被連結的 function 還必須在產生 html 的 function 的 local 中定義。結果 View 和 Controller 無法分開放在兩個不同的 modules。

在 GUI 還不盛行的時代，撰寫交談式程式的概念十分簡單，就是先印出問題等待使用者回答，使用者回答後再根據使用者的回答進行處理。GUI 的複雜度使得我們必須使用 MVC 這樣的概念。程式流程的控制權轉到了使用者的手裡。但至少 VIEW 和 Controller 都還在同一台電腦上，資料得以互通。到了網路時代，WEB 程式的撰寫更為困難，因為人機界面落在另一台電腦，在伺服端的程式並不知道使用者正在觀看哪一個畫面。當使用者下命令時，伺服端程式只能從 request 來猜出使用者的要求，沒有 continuation 的設計時，request 內只有這次要求的資料，看不出過去要求的歷史，無法處理複雜的，必須依據使用者過去瀏覽的歷史處理的運算。

這樣說來，如果 Continuation 能把事情簡化到最早期的程式撰寫方法，則 MVC 的概念並不是一定必要的。

Macro 的不可或缺

原本我的遊戲是以 javascript 寫成。在研讀過 PLT Scheme 的手冊後，我開始以 scheme 改寫我的遊戲軟體。 這樣做的原因主要是我欣賞 PLT scheme 中提供的 @-exp 語法。這語法類似 XML，適合用來描述遊戲的劇本，又和 scheme 完美整合。

將劇本以 @-exp 改寫後，我發現 macro 的重要性。以下是我劇本的一個片段：

@novel["家變"]{
  @room["書房"]{
    @scene["牆壁"]{
      你面對一面白色牆壁。牆壁上有條裂縫。向上直達天花板。
      @next["檢查裂縫" #:scene "裂縫"]
      @next["檢查天花板" #:scene "天花板"]
    }
    @scene["天花板"］
      天花板有點潮溼。
    }
    @scene["裂縫"]{
      裂縫中有隻螞蟻。
    }
  }
}

面對這樣的劇本，有兩種作法：

1. novel 是 scheme function。此時，因為 room 會比 novel 早執行，因此，在執行 novel 前必須先建造一個名為 current-novel 的物件，或是使用一個 global 的物件，以存放 room 產生的資料。這使得劇本必須做小修改，而撰寫劇本的人，很可能不是一位程式設計師，必須操心這些小修改。
   
2. novel 是 scheme macro。由於使用 macro，可以將建造 current-novel 的工作包括在 macro 的設計中，因此，撰寫劇本的人就不必操心這些問題。

我沒想到的是，單單劇本撰寫這樣原本以為簡單的工作，竟然也涉及到 macro 的撰寫，也因此體會了 macro 強大的能力。

在設計劇本的描述語言時，我也感受到 scheme 的 keyword 帶來的好處，以以上的劇本為例，在 next 中我使用了 #:scene 這個 keyword，它使得劇本更容易閱讀。

一個讓我驚訝的事是，我目前感受不到 PLT-Scheme 的 define-struct 的好處。原本我使用 (define-struct novel (name)) 來建立 novel 這結構，但最後我改成如同我原本使用 javascript 的作法，使用 hashtable，同時參考 SICP 的作法 來解決。

PLT-Scheme Contracts

一歩一歩讀著「Guide: PLT Scheme」，讀到 PLT Scheme 的 Contracts。我使用 Eiffel 的 Design by Contract 多年。感到 PLT Scheme 的 Contracts 設計過於瑣碎。缺少 Eiffel 的簡單明瞭容易使用。

但是 PLT Scheme 的支持者說 PLT Scheme 的設計是健全的。我不禁好奇又感到懷疑。Behavioral Contracts and Behavioral Subtyping 嘗試說明 Eiffel 的問題。但顯然文章的作者不瞭解 DbC。DbC 的設計，在繼承的子類別處，precondition 可以放寬， postcondition 則必須更緊縮。這文章不同意 DbC 的看法。舉了以下例子：J 繼承 I。J 和 I 都有一個函式 m (x)。m 的引數 x 在 I 中的要求是 x>0。在 J 中的要求是 x > 10。於是 Eiffel 的 DbC 認為使用 J 的 m 時 x 可以為 5。但這篇文章認為不行，使用 J 的 m 時 x 必須大於 10。我同意 DbC 的作法。J 是 I  的繼承者，必須繼承 I 的責任和義務。在 I 中認為只要 x > 0 就有資格使用 m 這個函式時，J 的函式設計就必須滿足這條件，否則，J 不應該繼承 I。J 中的 m 寫著 x > 10。只是說明 J 中的 m 承諾在 x > 10 時可以使用 m。透過繼承 J 還同時承諾了 x > 0 時也可以使用 m。因此，雖然 x > 10 這條件有點多餘，但不表示它是錯的。

這讓我對 PLT scheme 的 contracts 設計感到失望，也許這就是為何 PLT Scheme 一直無法推出 Class 的 contracts 的原因：他們根本想錯了。

風雨將至？Scheme 來援？

出於興趣，工作之餘，我撰寫網路游戲，透過這努力，我吸收新的，工作以外的專業技術。這是必須的，因為，工作的內容常一成不變，以致於人無法單靠工作成長。在技術瞬息萬變的軟體世界，不成長就等著被淘待。在休閒時撰寫網路游戲，使我能任意選擇我想要學習的技術，也沒有工作上必須完成的壓力，能依自己的狀況或快或慢，漸進地成長。

雖說技術瞬息萬變，但值得學習的常常是那些老舊的東西，那些老舊但又能持續推陳出新的東西。在此我指的是一種古老的語言：Scheme。我在前幾天發現 PLT Scheme 提供了 Web Server。

對於 Scheme 這語言，我早充滿好奇。一直沒能派它上用場，只能止於欣賞，無緣深入。我開始撰寫網路游戲時，未曾考慮它。我使用 Javascript，另一個我以為值得學習的語言。我以 Helma NG 為我開發的平台。在這過程中，我停歩了。我發覺自己需要一個 DSL以撰寫游戲的腳本。我考慮自行設計，或直接用 Javascript，前些時決定用 jLINQ+JSON。這組合總算初歩滿足我的需求。不幸，撰寫工作還是一停在停。

「一定是在哪兒有問題，讓游戲的撰寫工作少了一種流暢感。」我心想，「可能游戲複雜度將至的警訊。」

這流暢性的缺乏來自我的游戲中需要有能和資料完美結合的 DSL。但 Javascript 或 jLINQ 或 JSON 並不適合。

這時發現 PLT Scheme 提供了 Web Server 讓我十分開心。我打算以 Scheme 改寫游戲，評估它的實用性。希望這次能讓我進入 Scheme 的領域。