Gaucheプログラミング(立読み版)

すべて式である

Tue, 15 May 2007 11:24:02 +0900

Scheme では計算というのは式の値を求めることです。

Scheme の式は以下のように表現されているものです。

ひとつ塊(シンボルおよびリテラル)として表現されるもの(この構文のことをアトムということがあります)
複数の式を括弧((と))で囲って表現されるもの(この構文のことをリストということがあります)

1. により、map、string=?、*、-5、3.14、 "The Wizard Book"、#\a などはどれも式です。
2. により、(- 1 (* 2 3))、 (string->list (string-map char-upcase "wikiwiki")) なども式です。

式が表す値に名前をつけることを定義といいます。Schemeでは式が表す値に名前を付けることによって、複雑な構成の式をひとつのものとして抽象化して表現することができます。

計算機に計算をさせるには、対話型のインタプリタを使うのが簡単です。式が表す値はその式を評価(eval)すること、すなち計算することによって得られます。式が表す値を確認するために対話型のインタプリタを起動して計算をさせてみましょう。

コマンドラインでgoshとタイプするとインタプリタが起動します。

 $ gosh
 > _

起動するとインタプリタは> という入力促進記号(プロンプト)を出力して、ユーザからの入力待ち状態になります。ここで式をタイプして最後にリターンキーを押すとインタプリタはユーザがタイプした式を読み(read)、それを評価(eval)し、結果を印字(print)し、再びプロンプトを出して入力待ち状態になります。

 gosh> 1
 1
 gosh> _

他にも試してみましょう。

 gosh> "hello"
 "hello"
 gosh> (+ 1 3)
 4
 gosh> (let1 abs (lambda (n)
                      (if (<= 0 n)
                          n
                          (- n)))
            (abs -1))
 1

すべて式とはどういうことか

たとえば、Scheme では if は式なので値を返します。

a に「bの絶対値」を加算するプログラムを考えて見ましょう。絶対値を求める手続き abs を使わないとすると、

 (define (a-plus-abs-b a b)
   (if (>= b 0)
        (+ a b)
        (- a b)))

と書けます。これは if 式全体の値が手続き適用したときの値として返されます。また、if 式は値を返すので、その値そのものとみなすことができるので、

 (define (a-plus-abs-b a b)
   (+ a (if (>= b 0)
            b
            (- b)) ))

のように b の値の正負によって，b か -b を返すように書いています。さらに Scheme では手続きそのものも値ですので、手続きを値として返す式を書けます。以下の定義で if 式は b が正の値なら + 手続きを、負の値なら - 手続きを返しています。

 (define (a-plus-abs-b a b)
   ((if (> b 0)
          +
          -) a b))

例えば a が 23、b が 16 ならば、

((if (> 16 0) + -) 23 16)
↓
(+ 23 16)
↓
39

aが12、bが-74ならば、

((if (> -74 0) + -) 12 -74)
↓
(- 12 -74)
↓
86

と計算できます。

代入がなくても計算はできる

Schemeにおいて計算する対象はすべて式であるなら、代入文はないということになります。代入文がなくてプログラムが書けるのでしょうか。

書けます。

1 から指定した上限 n までの整数の和をもとめる計算を考えてみましょう。

 1 + 2 + ... + (n-1) + n

このプログラムを書くのに代入文が欲しいですか。こんな風に計算させようとしていますか。

s に 0 を代入
i に 1 を代入
i が n を超えない間 4 〜 5 を実行、n を超えたら 6 へ
s + i を計算してその結果を s に代入
i + 1 を計算してその結果を i に代入
s の値を印字

なるほど。これで計算できるような気がします。でもこれで本当に欲しいものが手にはいるかどうかは、よくよく読んで検討しないと分りませんね。

こんな風に欲しいものを「どのように」得るかの手順を考えるのではなくてもっと、単純に考えることもできます。これを行う関数を sum としましょう。こんな風に考えます。

n が 1 のとき、(sum n) の値は 1
n が 1 より大きいとき、(sum n) の値は、ひとつ手前 (n-1) までの和 (すなわち (sum (- n 1))) と n との和

これを書くと、

  (define (sum n)
    (if (= n 1)
        1
        (+ (sum (- n 1)) n)))

欲しいものが「何か」を書いただけです。でも欲しいものはちゃんと書けているということは分りますよね。どこにも代入は必要ありませんでしたね。

ではなぜ、最初は代入が必要だと思ったのでしょう。「プログラムは計算の手順を書いたもの」という先入観がどこかにありませんでしたか。

「Lisp脳」の謎に迫る - Schemeプログラマの発想

Fri, 23 May 2008 12:56:19 +0900

この原稿の最新版について
この原稿に加筆した最新版が書籍「プログラミングGauche」に収録されています。引用や紹介をされる方はなるべく書籍収録版を参照してください。

他の言語のプログラマがSchemeプログラムを書くとき、どうしても発想が手続き的(procedural)になりがちです。

LispプログラマやSchemeプログラマの発想は手続き的な発想とはどうも違うらしい、ということは分かるのですが、具体的に何が違うのでしょうか?

ここではこの謎に迫ってみましょう。

実例

例えばこんな例題があります。

1から100までの数をプリントするプログラムを書け。ただし3の倍数のときは数の代わりに「Fizz」と、5の倍数のときは「Buzz」とプリントし、3と5両方の倍数の場合には「FizzBuzz」とプリントすること。
どうしてプログラマに・・・プログラムが書けないのか?
(原題: Why Can't Programmers.. Program?)
Jeff Atwood / 青木靖訳
http://www.aoky.net/articles/jeff_atwood/why_cant_programmers_program.htm

「プリントすること」と書かれているので、手続き的プログラマこんな手順を考えるのではないでしょうか。

1から100までの数を繰り返し処理で処理する
繰り返し毎にその回の数を判定して条件分岐する
15で割りれるなら"FizzBuzz"を、5で割り切れるなら"Buzz"を、3で割り切れるなら"Fizz"を、さもなければ数のまま印字する

これを考えていくと、

「プリントってことは入出力を伴うよなあ」
「print手続きを毎回呼ぶんだよなあ」
「繰り返し処理ならforだけどSchemeにはないからdoかなあ」
「回数ごとに1づつ加算するにはGaucheだとinc!が使えるらしい」
「Schemeでは条件分岐にはcondが使えるのか」
「...」

などと連想が広がっていくことでしょう。

この発想を素直に書いたのが次のコードです。

(do ((x 1 (inc! x)))
    ((>= x 100) x)
  (cond ((= (modulo x 15) 0)
         (print "FizzBuzz"))
        ((= (modulo x 5) 0)
         (print "Buzz"))
        ((= (modulo x 3) 0)
         (print "Fizz"))
        (else
         (print (x->string x)))))

実行してみると1から100までの数を印字改行し、 3や5の倍数には仕様どおりに"Fizz" "Buzz" "FizzBuzz"が印字改行されています。めでたしめでたし。

Schemeプロラマがこんな風に考えないのだとしたら、いったい何が違うのでしょうか?

Schemeプログラマの発想

Schemeプログラマはたとえばこんな風に発想します。

「とりあえず1から100までのリストを作れば良さそうだ」

と考えて、まずこんな風に書いてみます。

 gosh> (use srfi-1)
 #<undef>
 gosh> (iota 100 1)
 (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80
 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100)

つぎに、

「mapを使ってこのリストを加工して、別のリストを返せばいいじゃん」

と考えます。

 (map
  何らかの加工
  (iota 100 1))

map式では元のリストの要素すべてに「何らかの加工」を行うと新たなリストが返って来ます。あとはこの「何らかの加工」の中身を考えれば良さそうです。

「何らかの加工」の中身ですが、 Schemeプログラマは「プリントせよ」という文を読んだからといって素直に「印字せよ」とは考えません。 (このへん若干誇張されている恐れあり)

「その要素を置き換えておけば、出力は後からどうにでもなるじゃないか」

と考えて、

  (cond ((= (modulo x 15) 0)
         (print "FizzBuzz"))
        ((= (modulo x 5) 0)
         (print "Buzz"))
        ((= (modulo x 3) 0)
         (print "Fizz"))
        (else
         (print (x->string x))))

とprint式を書く代わりに、

  (cond ((= (modulo x 15) 0)
         "FizzBuzz")
        ((= (modulo x 5) 0)
         "Buzz")
        ((= (modulo x 3) 0)
         "Fizz")
        (else
         x))

と値を返すだけで満足してしまいます。

 (map
  (lambda (x) (cond ((= (modulo x 15) 0) "FizzBuzz")
                    ((= (modulo x 5) 0) "Buzz")
                    ((= (modulo x 3) 0) "Fizz")
                    (else x)))
  (iota 100 1))

実行してみると確かに問題の仕様どおりのリストが返るので、

「プリントせよ? 対話型インタプリタで実行すれば結果のリストはインタプリタが印字してくれるじゃないか」

とも考えるのですが、

「まあ結果のリストをprintしてみても良いか」

とも考えて全体をprint式で包んでみたりもするかも知れません。

 gosh> (print
        (map
         (lambda (x) (cond ((= (modulo x 15) 0) "FizzBuzz")
                          ((= (modulo x 5) 0) "Buzz")
                          ((= (modulo x 3) 0) "Fizz")
                          (else x)))
         (iota 100 1)))
 (1 2 Fizz 4 Buzz Fizz 7 8 Fizz Buzz 11 Fizz 13 14 FizzBuzz 16 17 Fizz 19
 Buzz Fizz 22 23 Fizz Buzz 26 Fizz 28 29 FizzBuzz 31 32 Fizz 34 Buzz Fizz
 37 38 Fizz Buzz 41 Fizz 43 44 FizzBuzz 46 47 Fizz 49 Buzz Fizz 52 53 Fizz
 Buzz 56 Fizz 58 59 FizzBuzz 61 62 Fizz 64 Buzz Fizz 67 68 Fizz Buzz 71
 Fizz 73 74 FizzBuzz 76 77 Fizz 79 Buzz Fizz 82 83 Fizz Buzz 86 Fizz 88 89
 FizzBuzz 91 92 Fizz 94 Buzz Fizz 97 98 Fizz Buzz)
 #<undef>

もちろん要素ごとに印字して改行したければ、

(for-each print
          (map
           (lambda (x) (cond ((= (modulo x 15) 0) "FizzBuzz")
                             ((= (modulo x 5) 0) "Buzz")
                             ((= (modulo x 3) 0) "Fizz")
                             (else x)))
           (iota 100 1)))

for-eachを使ってリストの要素それぞれに対してprintを適用しても良いでしょう。

結局何が違うのか?

手続き的な発想では、毎回特殊な処理を行いそれを繰り返すという発想でプログラミングしていました。

Schemeプログラマはそうは考えません。

データからデータへの変換を考えれば良く、出力は後からどうにでもなる、と考えています。

別の側面から見てみましょう。

 (map
  何らかの加工
  (iota 100 1))

データからデータへの変換を行っている「何らかの加工」の部分は、例えば問題の条件が増えたとしても、いくらでも差し替えが可能です。

これを、「Schemeプログラマの発想はモジュール性が高い」と理解しても良いのですが、 Schemeプログラマは最初から「モジュール性が高くなるように設計しよう」と意図して発想しているのではないのです。

むしろ「データからデータへの変換をしておけばいいじゃん」とだけ考えていたら結果としてモジュール性が高くなってしまったと理解するべきです。

Schemeプログラマの発想の一端がお分かりいただけたでしょうか?

リスト要素の破壊的変更

Tue, 08 May 2007 15:02:30 +0900

空リスト以外のリストは対(pair)で構成されています。対の要素の値はcarとcdrで参照することができます。

  gosh> (define lst (cons "abc" (cons 3 '())))
  lst
  gosh> lst
  ("abc" 3)
  gosh> (car lst)
  "abc"
  gosh> (cdr lst)
  (3)

carとcdrで参照できる要素の値を破壊的に変更する手続きがset-car!とset-cdr!です。

  gosh> (set-car! lst #\r)
  #<undef>
  gosh> lst
  (#\r 3)

まず対のcar要素を文字#\rに置き換えました。

  gosh> (set-cdr! lst '(a b c))
  #<undef>
  gosh> lst
  (#\r a b c)

つぎに対のcdr要素をリスト(a b c)に置き換えました。

面白い使い方としては対の要素に自分自身を代入することもできます。

  gosh> (define lst (list 2 "hello" 3 a #\b))
  lst
  gosh> lst
  (2 "hello" 3 a #\b)

  gosh> (set-car! lst lst)
  #<undef>
  gosh> lst
  #0=(#0# "hello" 3 a #\b)

ここではリスト(2 "hello" 3 a #\b)のcarにこのリスト自身を代入しました。

carを取り出してみると

  gosh> (car lst)
  #0=(#0# "hello" 3 a #\b)
  gosh> (car (car lst))
  #0=(#0# "hello" 3 a #\b)

同じ値が返されます。ここで、

  #数=値

は値に#数という名前をつけ、

  #数#

で、#数の名前が指している値を参照するということになっています。この機能を使うと循環したリストを作成できます。

コラム: リストリテラルは破壊的に変更してはいけない
Schemeでリストリテラルを破壊的に変更するのはエラー(誤り)です。破壊的に変更することが可能なのはconsやlistで構築されたリストだけです。
例えばリストリテラルに束縛されたlstを定義したとします。
 gosh> (define lst '(1 2 3))
 lst
 gosh> lst
 (1 2 3)
set-car!でlstの要素を破壊的に変更してみます。
 gosh> (set-car! lst 100)
 #<undef>
 gosh> lst
 (100 2 3)
このコードは現状のGaucheバージョン0.8.10で動作してしまいますが、 Schemeの仕様上はエラーです。
コラム: エラーのときのScheme処理系の振舞い
Schemeの現在の仕様であるR5RSでは、リスト要素が破壊的に変更されたときをはじめ、エラーのとき何が起こるべきかについて規定していません。このためエラーでの動作は処理系ごとに異なります。
Schemeの次期仕様であるR6RSではエラー時に何が起きるべきか、もっと厳密に定められる予定です。
もしリストリテラルを変更する必要があるなら、 list-copy手続きでコピーを作成し、コピーの方を破壊的に変更してください。
 gosh> (define lst '(1 2 3))
 lst
 gosh> lst
 (1 2 3)
 gosh> (define lst-cp (list-copy lst))
 lst-cp
 gosh> lst-cp
 (1 2 3)
 gosh> (set-car! lst-cp 100)
 #<undef>
 gosh> lst
 (1 2 3)
 gosh> lst-cp
 (100 2 3)
リテラル値、つまり定数値を破壊的に変更してはならない原則は、例えば文字列リテラルについても同様です。
 gosh> (string-set! "abc" 0 #\x)
 *** ERROR: attempted to modify an immutable string: "abc"
 Stack Trace:
 _______________________________________

執筆時点でのGaucheバージョン

Wed, 02 May 2007 11:22:20 +0900

本書執筆時点(2007年5月)でのGaucheバージョンは0.8.10です。

本書執筆時点でのKahuaバージョンは1.0.3です。

本書の使い方

Wed, 02 May 2007 11:18:00 +0900

本書の読み方

Gaucheの設計思想や開発の背景を手早く知りたい読者はまず「第1部思想」を読んでください。

「第2部文法」は最初から通して読まずに、どこからでも読み始められるように書いています。興味のあるトピックから読んでください。

「第3部実用」はチュートリアル形式で少しづつ改良しながらCGIプログラムを完成させます。他の言語の開発経験があるなら「第1部思想」の後に「第3部実用」を読んでも良いでしょう。

本書のソースコードや実行例の使い方

対話型インタプリタの実行例が示された箇所については、読者もまた対話型インタプリタを起動して、実際に入力して動作を確かめてみると理解が早いでしょう。

対話型インタプリタを使うためにはまずGaucheをインストールする必要がありますが、 Gaucheのインストールについては「付録」で説明しています。

対話型インタプリタの起動方法や使い方については「第2部文法」の「対話型インタプリタgosh」で説明しています。

対話型インタプリタを単独で起動するほか、対話型インタプリタをEmacsエディタ内部で起動し、ソースコードを編集しながら部分的に評価させることができます。

この技法はScheme言語プログラムの開発で頻繁に使われ、しかも強力です。

Emacsから対話型インタプリタを使う方法については「第2部文法」の「EmacsからGaucheを使う」で説明しています。

本書の表記

Wed, 02 May 2007 10:53:10 +0900

ソースコード

ソースコードは固定幅フォントで表記します。

例:

 (lambda (x) (* x x))

対話型インタプリタ

Gaucheの対話型インタプリタでの実行例は gosh> と書かれた入力プロンプトと供に表記します。

例:

 gosh> (list 0 1 2 3)
 (0 1 2 3)

上記の例でプロンプトに続く(list 0 1 2 3)はユーザー入力をあらわし、斜体になった(0 1 2 3)はインタプリタが印字した評価結果をあらわします。

コメント(注釈)

ソースコード中の;(セミコロン)で始まる箇所はコメント(注釈)を表します。

例:

 gosh> (exact? 100) ;; 整数は正確数である
 #t

引数名の強調

手続きの説明で引数名を強調したいとき斜体や太字を使用することがあります。

例:

 (define (weekday-name index)
   (let ((day-names ((list "日" "月" "火" "水" "木" "金" "土")))
    (if (or (< index 0)
            (> index 6))
        #f
        (list-ref day-names index))))

はじめに

Wed, 02 May 2007 10:27:50 +0900

GaucheはScheme言語処理系のなかでもきわめて実用的で軽快な処理系です。豊富なライブラリが用意され、スクリプト言語処理系として手軽に使うことができます。

本書ではScheme言語の基本概念をはじめ、Gaucheの設計思想や開発の背景、Gaucheでのプログラミングの実際を実例とともに紹介して行きます。

長い歴史を持つLisp系言語がなぜハッカーたちに愛され続けるのか、多くの読者がその理由の一端に触れられますように。

2007年5月 Kahuaプロジェクト一同

謝辞

Sat, 07 Apr 2007 17:43:54 +0900

査読に協力していただいた2ちゃんねるプログラム板「Lisp Scheme」スレのみなさんに感謝します。

CGIのユニットテストを書く

Sun, 01 Apr 2007 16:15:40 +0900

CGIのユニットテストを書く

www.cgi-testライブラリを使ってCGIスクリプトを実際に動作させるテストが作れます。

CGIに含まれる関数群はモジュール化してgauche.testの単体テストを行い、CGIのファンクショナルテストにwww.cgi-testを使いましょう。

「www.cgiライブラリを利用する」で書いたhello.cgiのテストを書いてみましょう。

テストコードはtest-hello.scmというファイル名にして、hello.cgiと同じフォルダに置いてください。

(use gauche.test)
(use www.cgi-test)

(test-start "CGI Test")

(test* "Hello Gauche"
       "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01//EN\"\n       \"http://www.w3.org/TR/html4/strict.dtd\">\n<html><body><p>Hello, Gauche!</p\n></body\n></html\n>"
       (values-ref (run-cgi-script->string
                    "./hello.scm"
                    :environment '((REQUEST_METHOD . "GET")))
                   1)
       )

(test-end)

通常のユニットテストと違い、gauche.testに加えてwww.cgi-testを読み込みます。

次の箇所でwww.cgi-testの関数を使っています。

       (values-ref (run-cgi-script->string
                    "./hello.cgi"
                    :environment '((REQUEST_METHOD . "GET")))
                   1)

run-cgi-script->stringはCGIスクリプトを実行し、その結果をHTTPヘッダのリストと文字列の二つの値(多値)にして返す関数です。このテストではヘッダーの値はテストしないので、values-refで二つ目の値(0から始まるので二つ目は1)になる文字列だけを取得しています。ここで得られる文字列はhello.cgiが返すHTMLそのものなので、test*で比較する値はブラウザが受けとるHTMLをそのまま書いています。

run-cgi-script->stringの引数は左から順にCGIスクリプトのパス、オプション引数で環境変数とCGIに渡すパラメータを指定できます。

パラメータを渡す例:

; hello.cgi?name=TAROU&age=12とアクセスした場合
(run-cgi-script->string
        "./hello.cgi"
        :environment '((REQUEST_METHOD . "GET"))
        :parameters '((name . "TAROU")
                      (age . 12)))

以上のようにしてCGIスクリプトをHTTPサーバを使わずに実行してテストすることができます。

www.cgi-testには、run-cgi-script->stringと返り値の種類が違う同種の関数が用意されています。

run-cgi-script->string-listは行単位の文字列のリストにして返します。 run-cgi-script->sxmlはHTMLやXMLをS式で表わすSXMLにして返します。実際のアプリケーションは複雑で大きなHTMLを返します。そのようなHTMLから一部分を抽出して比較したい場合にrun-cgi-script->stringは不便です。SXMLにするとHTMLがSchemeのリストになるため、高度な処理が簡単に記述できるようになります。Gacuhe作者の川合氏が作っているWikiエンジンのWiLiKiにはSXMLのパターンマッチを使ったテスト用ライブラリsxml.xml-testがあります。是非参考にしてください。

ユニットテストを書く

Fri, 30 Mar 2007 21:29:12 +0900

ユニットテストを書く

gauche.testライブラリを使ってユニットテストを作れます。

例えば、二乗を計算する関数squareのテストを書いてみましょう。

squareの定義(実はバグがあります):

(define (square n) (+ n n))

squareのユニットテスト:

(use gauche.test)

(test-start "square test")

;;一つ目のテスト群
(test-section "test group 1")
(test* "square 3" 9 (square 3))
(test* "square -2" 4 (square -2))

;;二つ目のテスト群
(test-section "test group 2")
(test* "pass string argument" *test-error* (square "a"))

(test-end)

このユニットテストでは三つのテストを用意しています。一つ目は3の二乗が9であることを、二つ目は-2の二乗が4であることをテストしています。三つ目は、引数に文字列を渡したときにエラーが起きることをテストしています。

テストの始まりにはtest-start、終わりにはtest-endを必ず書きます。 test-startの引数に書いた文字列はテスト実行時にプリントされるテストログに使われます。 test-sectionを使ってテストを分類するとたくさんのテストがあるときにテストログを分かりやすくできます。

test*はテストを行うマクロです。引数は左から順に、テスト名、期待する結果、テストする式です。テストする式の結果と期待する結果を比較し、結果が#tなら成功、#fなら失敗します。オプション引数compareで比較を行う手続きを指定できます。compareを指定しないとequal?を使って比較が行われます。このマクロはtest関数に展開されます。test関数はテストする式をthunk(引数無しの手続き)の形で書かなければいけないので、test*マクロを使ったほうが楽に書けます。

test関数でテストを書いた場合はこのようになります。

(test "square 3" 9 (lambda () (square 3)))

期待する結果に*test-error*変数を使うと、エラーが起きることを確認するテストを作れます。

それでは、実際にユニットテストを行うスクリプトファイルを作りましょう。

テスト対象のsquareの定義をsquare.scm、ユニットテストをtest-square.scmに書くことにします。二つのファイルは同じフォルダ内に置いてください。

test-square.scm:

(use gauche.test)

(add-load-path ".")
(load "square")

(test-start "square test")

;;一つ目のテスト群
(test-section "test group 1")
(test* "square 3" 9 (square 3))
(test* "square -2" 4 (square -2))

;;二つ目のテスト群
(test-section "test group 2")
(test* "pass string argument" *test-error* (square "a"))

(test-end)

テストを始める前に、テスト対象のsquare関数をloadしています。 add-load-pathでユニットテストファイルと同じ場所にあるsquare.scmをロードできるようにしています。ファイルをloadするとsquareの定義が読み込まれます。テスト対象のファイルがモジュール化されているなら、loadの代わりにuseを使うといいでしょう。

それではユニットテストファイルを実行してみましょう。テスト結果がプリントされます。

テスト結果:

$ gosh test-square.scm
Testing square test ...                                          
<test group 1>-----------------------------------------------------------------
test square 3, expects 9 ==> ERROR: GOT 6
<test group 2>-----------------------------------------------------------------
test square -2, expects 4 ==> ERROR: GOT -4
test pass string argument, expects #<error> ==> ok
failed.
discrepancies found.  Errors are:
test square 3: expects 9 => got 6
test square -2: expects 4 => got -4

二つのテストに失敗してしまいました。プリントされたログをみると、3の二乗が6、-2の二乗が-4になっています。squareにバグがあるので修正しましょう。

squareの定義(バグを修正済み):

(define (square n) (* n n))

squareを修正したので、もう一回テストを実行してみましょう。

テスト結果:

$ gosh test-square.scm
Testing square test ...                                          
<test group 1>-----------------------------------------------------------------
test square 3, expects 9 ==> ok
<test group 2>-----------------------------------------------------------------
test square -2, expects 4 ==> ok
test pass string argument, expects #<error> ==> ok
passed.

テストに成功しました。

複数のユニットテストをまとめて実行したいときにはMakefileを使うといいでしょう。ログファイルを一つにしておくと、確認するときに便利です。

test :
     gosh my-feature-test1.scm >> test.log
     gosh my-feature-test2.scm >> test.log
     gosh my-feature-test3.scm >> test.log

SRFI

Fri, 30 Mar 2007 17:01:44 +0900

SRFIとはSchmeme Request for Imprementanionの略です。 SRFIは、Schemeの言語仕様であるR5RSには書かれていない多くの機能を提供するライブラリです。

http://srfi.schemers.org/

SRFIについての情報は上記URLで管理されています。

SRFIはScheme処理系に依存しない共通ライブラリ集です。SRFIを使うことでSchemeプログラムの移植性を高めることができます。

GaucheではいくつかのSRFIライブラリを、Gaucheに付属するモジュールとしてサポートしています。

srfi-0	機能条件式
srfi-1	リストライブラリ
srfi-4	単一型のベクタ
srfi-5	シグネチャとrest引数に互換性のあるlet形式
srfi-7	機能ベースプログラム設定言語
srfi-9	レコード型
srfi-11	Let-values
srfi-13	文字列ライブラリ
srfi-14	文字集合ライブラリ
srfi-19	時間のデータ型と手続き
srfi-27	ランダムビットのソース
srfi-29	地域化
srfi-37	args-fold プログラム引数処理
srfi-42	先行評価的内包表記
srfi-43	ベクタライブラリ
srfi-55	require の拡張

これらのうち特によく使われるのはsrfi-1のリストライブラリ、srfi-13の文字列ライブラリです。本書では第1部「すべて再帰である」でsrfi-1を、第2部「文字集合」でsrfi-14を、「多値」でsrfi-11を、第3部「スケジュールCGIを書こう」でsrfi-1、srfi-13、srfi-19を使用しています。

詳しい内容についてはGaucheのリファレンスマニュアルやSRFIの情報サイトを参照してください。

組み込みでサポートされるSRFIライブラリ

モジュールとして提供される以外に、GaucheではいくつかのSRFIライブラリを組み込みでサポートしています。代表的なものは以下です。

SRFI-2	AND-LET: 局所束縛をともなう AND、ガード付 LET 特殊フォーム
SRFI-6	基本文字列ポート
SRFI-7	機能ベースプログラム設定言語
SRFI-8	receive: 多値束縛
SRFI-10	Sharp-comma外部フォーム
SRFI-16	可変長引数手続き構文 (case-lambda)
SRFI-17	一般化された set!
SRFI-18	マルチスレッドのサポート
SRFI-22	UNIX 上の Scheme スクリプトの実行
SRFI-23	エラー報告機構
SRFI-26	カリー化をともなわないパラメータの特殊化記法
SRFI-30	ネストした複数行コメント
SRFI-31	再帰評価用の特殊フォーム rec
SRFI-34	プログラムの例外処理
SRFI-35	コンディション
SRFI-38	共有されるデータの外部表現
SRFI-45	反復的 Lazy アルゴリズムのための基本関数
SRFI-55	require-extension
SRFI-61	より汎用的なcond節
SRFI-62	S式コメント
SRFI-61	case節での=>

詳しくはGaucheリファレンスマニュアルの標準への準拠を参照してください。

eval

Tue, 03 Apr 2007 14:03:45 +0900

evalは与えられたデータをSchemeの式として解釈し、実行する手続きです。

eval expr env

exprは、Schemeの式として解釈可能な(妥当な)データを表す式であり、envはその式を解釈・実行する際の環境を表すオブジェクトです。これだけだとわかりにくいので、例を挙げてみましょう。

gosh> (eval '(+ 1 2) (interaction-environment))
3
gosh>

ここで、第1引数に(+ 1 2)を'(+ 1 2)を渡していることに注目して下さい。 evalは手続きですから、引数は必ず評価されてからevalに渡されます。従って

gosh> (eval (+ 1 2) (interaction-environment))
3
gosh>

というのは、

gosh> (eval 3 (interaction-environment))
3
gosh>

と同じことになってしまいます。

第2引数には、R5RSに以下の手続きが返す値を渡すことが定められています。

(interaction-environment)	実装定義の束縛を含む環境を返す
(scheme-report-environment 5)	R5RSで規定されている束縛のみを含む環境を返す
(null-environment 5)	R5RSで規定されている構文キーワードのみを含む環境を返す

ただし、Gaucheにおいてはこれらの手続きが返す「環境」は単にモジュールなので、第2引数に任意のモジュールを渡すことができます。

Gaucheインストール

Wed, 28 Mar 2007 13:58:59 +0900

本書執筆時点でのバージョン

本書執筆時点(2007年3月現在)でのGaucheのバージョンは0.8.9です。

動作環境

本書執筆時点(2007年3月現在)でGaucheはLinux、FreeBSD、Mac OS XをはじめとするいくつかのUNIX互換OSで動作しています。

Kahuaを動作させるためのGauche configureオプション

Kahuaを動作させるためには以下のオプションでGaucheのconfigureを実行してください。

 ./configure --enable-threads=pthreads --enable-multibyte=utf-8

Kahuaが動作するためにはマルチスレッドが必須です。 --enable-threads=pthreadsオプションを必ず指定してください。

Kahuaで日本語を含むマルチバイトを扱う場合、特別な理由がない限り--enable-multibyte=utf-8オプションを指定し、 Gaucheの内部エンコーディングをUTF-8にしてください。

Gaucheは開発中のシステムであり、頻繁に更新されています。動作環境、インストールをはじめとする最新の情報については、常に次のURLを参照してください。 http://practical-scheme.net/gauche/

簡単な方法

   % ./configure [--enable-threads=pthreads]
   % make
   % make test
   % make install

これで、Gaucheシステムが /usr/local/bin, /usr/local/lib/gauche及び /usr/local/share/gauche以下にインストールされます。マルチスレッドサポートを使うためにはconfigureに--enable-threads=pthreadsを渡して下さい。このオプションはいくつかのプラットフォームでサポートされています。

既にGauche 0.5以降がインストールされているシステムで、全く同じconfigurationオプションで新しいバージョンのGaucheをインストールする場合、'configure' の代わりに次のコマンドを使うこともできます。

    % gauche-config --reconfigure | sh

'--reconfigure' オプションが与えられると、gauche-configは現在インストールされているGaucheがconfigureされた時のコマンドラインを標準出力に書き出します。それをシェルに評価させれば、同じオプションで configureすることができます。

文字エンコーディングの選択

デフォルトでは、Gaucheは内部文字エンコーディングとしてutf-8を使います。 --enable-multibyte=ENCODING というオプションをconfigureに渡すことで、内部文字エンコーディングを変えることができます。

  ./configure --enable-multibyte=utf-8   ;; UTF-8 (default)
  ./configure --enable-multibyte=euc-jp  ;; EUC-JP
  ./configure --enable-multibyte=sjis    ;; Shift JIS
  ./configure --enable-multibyte=no      ;; No multibyte string

Gaucheは代表的な日本語文字エンコーディングを認識し変換することができますが、それ以外のエンコーディングに関しては、iconvが利用可能であればそれを利用して変換を行います。 iconvが標準でインストールされていないシステムでは、 --with-iconvオプションで外部のiconvライブラリを利用することができます。

  ./configure --with-iconv=DIR

例えば --with-iconv=/usr/local とすれば、Gaucheはiconv.hを/usr/local/include から、libiconvを/usr/local/libから探します。もしあなたのiconvライブラリが libiconv以外の名前 (libmyconvとか) だったとしたら、 --with-iconv-lib=myconv というオプションも指定して下さい。

外部のiconvライブラリとしては、Bruno Haible氏のlibiconvが以下から入手可能です。 http://www.gnu.org/software/libiconv/

ローカルライブラリパス

Gaucheのビルドに、標準でない場所にインストールされているライブラリを使用したい場合、次のオプションでその場所を指定することができます。

  --with-local=PATH:PATH2:...

これで、PATH/include、PATH2/include、... がインクルードパスに、 PATH/lib、PATH2/lib、... がライブラリサーチパスに追加されます。

例えば、/usr/localにインストールされたgdbmライブラリを使用したい場合は次のようにします。

  --with-local=/usr/local

IPv6サポート

Gaucheは実験的にIPv6をサポートしています。デフォルトではこの機能はoffになっていますが、次のconfigureオプションで有効にすることができます。

  --enable-ipv6

もちろん、OSでIPv6がサポートされていなければなりません。現在の実装はFreeBSD上でテストされています。詳しい機能はリファレンスマニュアルのgauche.netの項を参照して下さい。

SLIBの場所

SLIBは、ポータブルなSchemeライブラリで、いろいろ便利な機能が完全にSchemeで書かれています。GaucheはSLIBがインストールされていればその機能を利用することができます。

configureスクリプトは、/usr/local/slibなどいくつかの基本的なディレクトリからSLIBを自動的に探します。もしあなたのSLIBシステムが標準的ではない場所にインストールされていたら、次のオプションでその場所を指定してください。

   ./configure --with-slib=PATH

ここで、PATHはSLIBがインストールされたパスです。

GauchehはSLIB無しでも動作します。SLIBを使う必要がなければ、このオプションは気にしなくてよいです。

SLIBは最初に使う前にGaucheのライブラリディレクトリにカタログファイルを作成します。Gaucheのインストール時に既にSLIBが存在すればインストールスクリプトがカタログファイルを作成しますが、Gaucheインストール後にSLIB がインストールされた場合、最初にSLIBを使おうとした時点でカタログファイルが作成されます。この時、Gauche使用者がライブラリディレクトリに書き込み権限を持っていないとエラーとなります。書き込み権限を持つユーザがgoshを起動して例えば次のような式を評価すればカタログファイルが正しく作られます。

  (use slib)
  (require 'logical)

実行時のライブラリパス

しばしば、環境のコントロールができない箇所でGaucheを走らせなければならない場合があります。例えばCGIスクリプトをISPのサーバーで走らせる場合などです。もし、Gaucheが標準的でない場所にインストールされた共有ライブラリに依存している場合、それが問題となります。

例えば、最新のlibiconv.soを自分でコンパイルして /home/yours/lib にインストールしたとします。--with-iconv=/home/yours/lib としてconfigure すれば、Gaucheはあなたのiconvを使うようにコンパイルされます。実行時に適切な環境変数、例えばLD_LIBRARY_PATHなどを設定しておけば、Gaucheのインタプリタgoshはlibiconv.soを捜し出すことができます。しかし、 CGIスクリプトはWeb serverによって起動され、Web serverはLD_LIBRARY_PATH を設定してくれないかもしれません。その場合、goshはlibiconv.soが見つけられずに起動に失敗するかもしれません。

コンパイラによっては、プログラムが依存している共有ライブラリのパスをプログラム本体に書き込んでしまえるオプションを持っています。configureの --with-rpath オプションはそれを利用します。--with-rpath=DIRとすると、実行時にDIRから共有ライブラリを探すような設定になります。このオプションは今のところgccでしか動作しません。

インストール先の指定

次のようにconfigureスクリプトを起動することにより、インストール先のディレクトリを指定できます。

   % ./configure --prefix=$PREFIX  --exec-prefix=$EXEC_PREFIX

--prefix オプションが指定されなければ、 /usr/local が指定されたものとみなされます。 --exec-prefix オプションが指定されなければ、EXEC_PREFIXはPREFIXと同じものになります。

インストールされるファイルの内訳は以下の通りです。

  $EXEC_PREFIX/bin/*
     インタプリタ (gosh) とコンフィグレーションスクリプト (gauche-config)

  $EXEC_PREFIX/lib/*
     ライブラリ (libgauche.a).

  $PREFIX/share/gauche/VERSION/include/*
     libgaucheをリンクするアプリケーションに必要なヘッダーファイル

  $PREFIX/share/gauche/VERSION/lib/*
     マシンに依存しないSchemeファイル

  $PREFIX/share/info/*
     infoファイル

  $EXEC_PREFIX/lib/gauche/VERSION/ARCHITECTURE/*
     マシンに依存するファイル (.so, gosh, gauche-config, libgauche.a)

  $PREFIX/share/gauche/site/lib/*
  $EXEC_PREFIX/lib/gauche/site/VERSION/ARCHITECTURE/*
     ユーザが独自にインストールするマシン非依存／依存ファイルのデフォルトの置き場所。

最適化オプション

Make時に、makeマクロOPTFLAGSを用いて追加のコンパイルオプションを指定することができます。configureが設定するOPTFLAGS以外のオプションを試したい場合は次のようにmakeを走らせて下さい。

  make OPTFLAGS="--some-compiler-option --other-option"

アンインストール

インストールされたGaucheソフトウェアを取り除くには、ソースツリーのトップディレクトリで

  make uninstall

として下さい。

機種依存の情報

MacOS X

dlcompatライブラリ(libdl)がインストールされていることが必要です。 http://fink.sourceforge.net からダウンロードできます。システム標準の場所以外にdlcompatライブラリをインストールした場合は、 configureの--with-localオプションで場所を指定して下さい。また、GCがpthreadsを要求するようになったので、--enable-threads=pthreads も必要です。 (例：$HOME/include に dlfcn.h が、 $HOME/lib に libdl.aがある場合は

    ./configure --with-local=$HOME --enable-threads=pthreads

とする)

IRIX with 64bit binary

デフォルトの32bit ABIではなく64bit ABIでコンパイルしたい場合は次のようにして下さい。

    CC="cc -64" AS="as -64" ./configure

Linux/Crusoe TM5800

最近のLinuxでは Crusoe TM5800がi686互換とされるようになったようですが、gc中でi686特有のprefetch命令を使っているところでコンパイルに失敗するという報告がありました。とりあえずのfixは、 configure後にgc/Makefile中の

   -DUSE_I686_PREFETCH

という記述を消してからmakeして下さい。

無限エクステントとガベージコレクション

Wed, 02 May 2007 15:13:43 +0900

無限エクステント

Schemeでは、その計算途中で生成される全ての値(より正確には、値を保持する領域)は無限の寿命を持ちます。値(を保持する領域)の生存期間をエクステントと呼び、「Schemeの値(を保持する領域)は無限のエクステントを持つ」と表現されます。スコープと混同しないように注意して下さい。Schemeにおいてスコープは、値につけた名前(つまり変数)の有効範囲であり、基本的に有限です。無限エクステントは、Schemeの大きな特徴の一つです。

この特徴を利用すると、例えば手続きの中に値(を保持する領域)を閉じ込めることができます。

gosh> (define-values (x-set! x-get)
        (let ((x 0))
          (values (lambda (val) (set! x val))
                  (lambda ()    x))))
#<undef>
gosh> (x-get)
0
gosh> (x-set! 1)
1
gosh> (x-get)
1

この例では、let式でxに束縛された値の領域は、let式を抜けても有効です。一方でxという名前自体は、let式を抜けたところで無効になっています。この領域には、x-set!、x-getという2つの手続きからのみ触ることができることになるわけです。これは、オブジェクト指向プログラミングで言うところの「カプセル化」の原始的な形であり、Schemeプログラミングにおいて比較的頻繁に使われる手法です。

ガベージコレクション

値(を保持する領域)の生存期間が無制限だと説明しましたが、メモリは有限の資源です。それでも(通常は)メモリを使い切ることはありません。なぜでしょうか。

これは、以降の計算において全く参照されないことがわかっている値(を保持する領域)は、システムが回収して再利用するからです。このしくみを「ガベージコレクション(ごみ集め)」といいます。現在では、JavaやC#を始めとして、言語の枠組みにガベージコレクションが組み込まれていることは珍しくなくなりました。この仕組みがあるために、プログラマはメモリ管理にあまり気を使うことなくプログラミングを行うことができるのです。

ガベージコレクションの注意点

ガベージコレクションはプログラマをメモリ管理の煩雑さから解放してはくれますが、万能ではありません。ここでは、プログラマが気をつけるべきことをいくつか挙げておきます。

メモリ以外のリソース解放をガベージコレクションに任せない

ガベージコレクションを過信してしまったプログラマがやりがちな間違いは、メモリ以外のリソースの解放をガベージコレクションに任せてしまうことです。

例えば、以下のコードを見て下さい。

(define (some-file-op file)
  (let ((in (open-input-file file)))
    ... ;; ここでは明示的に (close-input-port in) していない
    ))

このsome-file-opは、明示的にファイルポートを閉じていません。確かにGaucheの実装では、変数inに束縛されたファイルポートがガベージコレクションによって回収される際、開けっ放しだったポートは閉じられます。しかし、逆に言えばガベージコレクションされるまではファイルポートは閉じられません。たいていのシステムにおいては、メモリよりもファイルポートの方が貴重な資源であり、手続きsome-file-op使い方によっては、ガベージコレクションが起こる前に、開けるファイルの数の上限に達してしまうでしょう。メモリ以外のリソースについては明示的に解放すべきなのです。Gaucheであれば、

(define (some-file-op file)
  (call-with-input-file file
    (lambda (in)
      ... ;; ここでは明示的に (close-input-port in) していない
      )))

とすることで、自動的にファイルポートを閉じることができます(が、これはScheme標準の機能ではありません)。

ループ内部でのローカル変数を避ける

あまりに頻繁に実行されるループの内側でアロケーションを発生させると、大きく効率を損なう場合があります。例えば、(あまり現実的な例ではありませんが)以下のコードを見て下さい。

 ...
 (let loop ((num 1000000000))
   (let ((vec (make-vector 100000)))
     (if (<= 0 num)
         ... ;; vecを使って計算した結果を返す
         (begin
           ... ;; vecを使って計算する
           (loop (- num 1))))))
 ...

ループを繰り返すたびに大きなベクタがアロケートされ、ループを終了したところで捨てられます(が、回収されるのは通常ずっと後です)。もちろん、計算の内容や値の返し方にもよりますが、単なる計算用のバッファとしてvecを使っているのであれば、次のようにした方が効率はずっと良くなります。

 ...
 (let ((vec (make-vector 100000)))
   (let loop ((num 1000000000))
     (if (<= 0 num)
         ... ;; vecを使って計算した結果を返す
         (begin
           ... ;; vecを使って計算する
           (loop (- num 1))))))
 ...

ただし、ここまで極端な場合を除けば、むしろあまり神経質にならないことをお薦めします。こうした効率化は一種の最適化と考えるべきです。早すぎる効率化はしばしば失敗に繋がります。特に効率が大きな問題になるまでは、あくまでもロジックに集中すべきです。

仮想マシン

Fri, 23 Mar 2007 16:22:27 +0900

Gaucheの仮想マシン(Virtual Machine, VM)はGauche処理系に組み込まれています。Gaucheの仮想マシンを単独で動作させることはできません。

例えば、コンパイル後の内部コードをGauche仮想マシンに外から与えて実行させることは(今のところ)できません。

Gaucheのコンパイルと実行について知っておくべきことは以下です。

プログラムの実行(eval)＝compile + executionである
Gaucheでは通常はトップレベルフォームごとにコンパイルと実行を行っている
特殊形式の解釈とマクロの展開はコンパイルの段階で行われる
コンパイル時の束縛によって最適化される手続きがある

プログラムの実行(eval)＝compile + executionである

Gaucheでは、プログラムの評価(eval)とはコンパイル(compile)+実行(execution)です。

 eval = compile + execution

コンパイルはコンパイラが行い、実行は仮想マシンが行います。

Gaucheではトップレベルフォームごとにcompileとexecutionを行っている

Schemeのプログラムは複数の式の並びから成ります。この式ひとつとつのことをトップレベルフォームと呼びます。

Gaucheでは通常このトップレベルフォームごとにコンパイルと実行を行っています。

特殊形式の解釈とマクロの展開はコンパイルの段階で行われる

ある条件のときだけモジュールを使用したいと思って、

 (if 条件式 (use モジュール名))

上記のif式を書いても意図どおりの結果にはなりません。特殊形式の解釈とマクロの展開はコンパイル時に行われるからです。

 gosh> (if #f (use gauche.threads))
 #<undef>

useマクロはif式の判定にかかわらず実行されています。

コンパイル時の束縛によって最適化される手続きがある

 gosh> (define (f x) (car x))
 f

リストにcarを適用する手続きfを定義しています。

 gosh> (set! car #f)
 #f
 gosh> car
 #f

手続きfの定義後にcarを書き換え、 car手続きを使えなくしてしまったらどうなるでしょうか?

 gosh> (f (list 1 2 3))
 1

f手続きで参照されているのはコンパイル時のcarなので、その後carが書き換えられても正常に動作しています。

コンパイラ

Fri, 23 Mar 2007 14:50:29 +0900

Gaucheはインタプリタですが、単なるインタプリタではなくいったんコンパイルしています。コンパイルされたコードはGaucheの仮想マシンで実行されます。

Gaucheのコンパイラは仮想マシンコンパイラです。コンパイル後のコードは仮想マシンで実行されます。

Gaucheがどんな内部コードにコンパイルするかを確かめるにはdisasm手続きが使えます。

 gosh> disasm
 #<closure disasm>
 gosh> (disasm (lambda (x) (* x x)))
 ''main_code (name=#f, code=0x81eecf0, size=4, const=0, stack=1):
 args: #f
      0 LREF0-PUSH               ; x
      1 LREF0                    ; x
      2 NUMMUL2                  ; (* x x)
      3 RET
 #<undef>

REPL

Fri, 23 Mar 2007 13:54:50 +0900

REPLとはRead Eval Print Loopの略です。つまり、読み込み(read)、評価(eval)、印字(print)を繰り返す(loop)ということです。

ほとんどのScheme言語処理系では、REPLを対話型インタプリタで提供しています。

処理系

Fri, 23 Mar 2007 13:52:18 +0900

ここではGaucheの言語処理系や動作環境についてとりあげます。

対話型インタプリタ(REPL)の使い方や、Gaucheがどのように動作しているか(コンパイラ、仮想マシン)、入出力をどう行うか、ライブラリを構築し利用するための仕組み(モジュールシステム)について説明します。

継続渡しスタイル

Wed, 16 Jan 2008 08:53:10 +0900

継続渡し形式

階乗factから始めましょう。

;; 階乗の普通の定義
(define (fact n)
  (if (= n 0)
      1
      (* n (fact (- n 1)))))

上記の階乗factの定義は

引数nが0なら1を返す(基底条件)
それ以外ならn-1の階乗にnを掛けたものを返す(再帰条件)

となっています。
これをfactから直接値を返すのではなく、返すべき値を継続手続きと呼ばれるものに渡します。継続手続き自体は特別な関数ではありません。単に、本来返り値を返すところで、その手続きに「あとはよろしく」と残りの処理を委ねてしまいます。そういう使い方をされる手続きのことです。

;; 継続渡し形式の階乗の定義
(define (fact/cps n cont)
  (if (= n 0)
      (cont 1)
      (fact/cps (- n 1) (lambda (a) (cont (* n a))))))

factとfact/cpsは何が違うのでしょうか? あるいは、どういう関係にあるのでしょう?

例えば、

(* 2 (fact 10))

という計算は、fact/cpsを使えば次の式と等価です。

(fact/cps 10 (lambda (a) (* 2 a)))

最初のfact式の例で(fact 10)式の返り値を待ち受けている処理(続きの計算)は (lambda (a) (* 2 a))で表現できるもの(返り値aをもらって2倍する処理)で、それが、fact/cpsにとっての継続手続きになっています。
なんだ、やってることは同じじゃないか?と思われれば、継続渡し形式はとりあえず理解できたと思って良いでしょう。

ただ、継続渡し形式では続きの計算を引数として渡しているので、 cont1 cont2 ... という具合に複数の続きの計算を渡すことが可能です。
例えば、

;; 除算
(define (divide num den)
  (/ num den))

この様に除算を定義するところを、以下の様に複数の継続手続きを渡せます。

;; 継続渡し形式の除算
(define (divide/cps num den pass fail)
  (if (= den 0)
      (fail num den pass fail)
      (pass (/ num den))))

passとfailは共に継続手続きです。次の様な使用方法が考えられるでしょう。

;; 非零の分母要求する除算
(divide/cps 10 0
            (lambda (a) (format #t "answer is ~a~%" a))
            (lambda (n d p f)
              (format #t "> ")
              (flush)
              (divide/cps n (read) p f)))

これは分母が0である内はプロンプトを出して入力を促し、非零の入力を受けとると除算を行って、答を"answer is ..."という形式で表示してくれます。 passを成功継続、failを失敗継続と呼ぶことがありますが、 3つ以上の継続手続きを渡すことも可能なのはあきらかです。

それともう一つ、継続渡し形式で書けば、現在実装中の関数(今の場合階乗fact)が、どういう形で結果を返すのが良いかの設計を遅らせることが出来ます。最終的に印字させることにしたのなら、

;; 結果の印字出力
(fact/cps 10 (lambda (a) (format #t "answer is ~a~%" a)))

とすればいいし、そのまま返すだけであれば、継続手続きとしてidentity(つまり(lambda (a) a))を渡すだけです。

;; fact/cpsでfactを定義
(define (fact n)
  (fact/cps n identity))

call/ccは普通の関数

[[Scheme]]にはcall/ccという呪文があって、大域脱出だの例外機構だのマルチスレッドさえ実装できる。とんでもなく柔軟な制御を可能にするらしい。

そう聞いてネット上のドキュメントを漁った方も多いのではないでしょうか。
しかし、call/ccは決して怪しい動作をするものではなく、ある意味、とても普通の関数です。
setjmp/longjmpのように、ちょっと奇妙なジャンプをするようなものという先入観もこの際捨ててしまいましょう。

まず、このことを理解してもらうために、call/ccなどと省略せずに、 call-with-current-continuationという正式名称に注目しましょう。きっと意識してなかった人も居るんじゃないでしょうか。 [[Scheme]]でファイルの入出力をしたことのある人ならこの名前の先頭についているcall-withというprefixを見てピンとくるでしょう。
そう、call/ccは他に類を見ない孤独で特殊な存在なんかではなく、良く見かけるcall-with系関数の仲間なんです。

call-with系関数

いくつか具体的な関数を紹介して感覚をつかんでもらえればよいでしょう。まず、あるファイルから読み込みを行う時に使う関数です。

;; call-with-input-fileの使用例
(define (count-chars file-name)
  (call-with-input-file file-name
    (lambda (in)
      (let loop ((c (read-char in))
                 (count 0))
        (cond ((eof-object? c) count)
              (else (loop (read-char in) (+ count 1))))))))

count-charsは引数として渡された文字列をファイル名とみなして、そのファイルをオープンして一文字ずつ読み込み、文字数をカウントしています。

注目してもらいたい関数はcall-with-input-fileです。
この関数は、

第一引数のファイルをオープンして、入力ポートを作り出す。
入力ポートを引数にして第二引数の手続きを呼び出す。

という処理を行っています。このcall-with-input-fileの処理はキモだけを抽出すると、次のコードになります。

;; とんでもなく杜撰なcall-with-input-fileの実装(コアのみ)
(define (call-with-input-file file-name proc)
  (proc (open-input-file file-name)))

つまり、call-with-input-fileは ファイルから入力ポートを作り出し、それを渡してprocをcallする という関数なのです。 call procedure with input fileという感じでしょうか。
実際にはclose-input-portで使い終わった入力ポートの後始末をする必要がありますが、ここでは省略しています。 call-with-input-fileが別のprocedureをcallする、という流れだけ理解してください。要はfileをopenしたりcloseしたりのお膳立て(あるいは環境整備)はするけど、自分では何も処理せずに、procedureにやらせるだけです。

では、出力の場合も見ておきましょう。

;; call-with-output-fileの使用例
(define (write-message file-name)
  (call-with-output-file file-name
    (lambda (out)
      (format out "I'm Schemer")
      (newline out)
      (flush out))))

やはり注目してもらいたいのは、call-with-output-fileの使い方です。

第一引数のファイルをオープンして出力ポートを作り出す。
出力ポートを引数にして第二引数の手続きを呼び出す。

すでに説明したcall-with-input-fileと見比べてください。

もちろん処理の方もほとんど同じで次の様になります。

;; とんでもなく杜撰なcall-with-output-fileの実装(コアのみ)
(define (call-with-output-file file-name proc)
  (proc (open-output-file file-name)))

call-with-output-fileもcall procedure with output fileと読めるでしょう。
これも実際にはclose-output-portで使用済みのポートを後始末するべきです。ここでは代わりに、write-message中でflushすることで書き出していますが、あくまで簡単にしてキモだけ見てもらうためです。やはり、call-with-output-fileが別のprocedureをcallしているという流れだけ理解してもらえれば十分です。

処理系によっては、これ以外にも文字列ポートやソケットなど多くのcall-with系の関数が標準で提供されているものもありますが、基本はどれも同じです。
[[Gauche]]であれば、replに対して次の様にすれば仲間が確認できます。

;; call-withのゆかいな仲間たち
gosh> (apropos 'call-with)
call-with-current-continuation (scheme)
call-with-input-file           (scheme)
call-with-input-file           (user)
call-with-input-string         (gauche)
call-with-output-file          (scheme)
call-with-output-file          (user)
call-with-output-string        (gauche)
call-with-string-io            (gauche)
call-with-values               (scheme)
gosh>

call-with-string-ioの様にprocに入力と出力の2つのポートを渡すものもありますが、 call-with系の関数はprocをcallする関数であるという点では変わりません。
その時にprocに何を渡すかによってバリエーションがあるだけなのです。

call-with-procedure

call-with系の関数は、一般化して言うなら、 fooの素からfooを生成し、procにfooを渡して呼び出す 関数ということになるでしょう。
call-with-input-fileやcall-with-output-fileでは、 fooは入力ポートや出力ポートであり、「fooの素」は文字列で与えられたファイル名ということになります。 call-with-string-ioならfooは入力ポートと出力ポートの組です。

では、仮にcall-with-procedureという関数を作るとしたら、どんな風になるかを考えてみましょう。
call-with-procedureという名前からすれば、 procedureの素からprocedureを生成し、procにprocedureを渡して呼び出す という関数になりますね。まぎらわしいがprocはcall-with-procedureの第二引数で与えられる手続きです。 procedureは、そのcallされるprocという手続きに渡される引数で、fooにあたります。ちゃんと区別してください。

まず、procedureの素とは何で表現されるべきでしょうか?
そう。lambda式を使うのが妥当でしょう。そうすると、次の様に言い換えられそうです。 lambda式からprocedureを生成し、procにprocedureを渡して呼び出す

;; call-with-procedureの実装
(define (call-with-procedure lambda-expr proc)
  (proc lambda-expr))

例えばこんな風に使えるようになるでしょう。

;; (* 2 (fact 10))
(call-with-procedure (lambda (a) (* 2 a)) (lambda (p) (p (fact 10))))

もちろん、こんな風に渡されたprocedureそのものを返してもいいですし、

;; 継続手続きを返すのみ
(call-with-procedure (lambda (a) (* 2 a)) (lambda (p) p))

新たに関数合成したものを返してもかまいません。

;; 継続手続きを関数合成して、出来た関数を返す。
(call-with-procedure (lambda (a) (* 2 a)) (lambda (p) (compose p p)))

渡されたprocedureを手続きとして使わなければならない法などありません。単にリストにして返すことだって一向にさしつかえありません、

;; 継続手続きをリストにして返す
(call-with-procedure (lambda (a) (* 2 a)) (lambda (p) (list p p)))

それどころか、そもそも引数を使わなくても別に文句を言われる筋合いはありません。

;; 継続手続きを使わない
(call-with-procedure (lambda (a) (* 2 a)) (lambda (p) "Hello World!"))

これはcall-with-input-fileやcall-with-output-fileでも言えることで、渡されたinやoutなどのポートを使わなくたって一向にかまいません。まるで意味はないですが。

call-with-continuation-procedure

では、もう一歩進めてcall-with-continuation-procedureを定義してみましょう。

;; call-with-continuation-procedureの定義
(define (call-with-continuation-procedure cont proc)
  (proc cont))

どうでしょうか?
call-with-procedureと変わらないじゃないかって?
それはその通りです。すでに説明した通り、継続手続きなんてのはただの関数なんだから当然です。せいぜいcall-with-continuation-procedureという名前から、 contというlambda式によって生成される手続きが (リストのメンバや関数合成の素などでなく) procの中で継続手続きとして使われるんだろう、と期待できる程度のことでしかないのです。

call-with-current-continuation

では、本題のcall/cc、つまりcall-with-current-continuationに話を移すことにしましょう。といっても、もうほとんどゴールに辿り着いていますが。

先程説明したcall-with-continuation-procedureは、継続手続きをプログラマが自分でlambda式として書いています。

(* 2 (fact 10))

この式の部分式である(fact 10)から見ると、(fact 10)式の続きの計算は (lambda (a) (* 2 a))になります。それを継続手続きとして渡してやると考えれば、

;; (* 2 (fact 10))
(call-with-continuation-procedure (lambda (a) (* 2 a))
                                  (lambda (cont) (cont (fact 10))))

こんな風に書けることになります。 (fact 10)の続きの計算を手動で作成している点が面倒ですが、このレベルならまだ書けなくはないでしょう。仮に、factがすでに定義済みなら、この式はfact/cpsの定義にできます。

;; fact/cpsをcall-with-continuation-procedureを使って定義する
(define (fact/cps n cont)
  (call-with-continuation-procedure cont (lambda (c) (c (fact 10)))))

ここまでは分かってもらえたでしょうか?

さて、続きの計算はいたるところにあります。あらゆる評価の時点において、その続きの計算というものが存在します。しかし、その時点を特定すれば、続きの計算は自動的に(一意に)決まることになります。
今の例で言えば、(fact 10)式の評価の時点において、その続きの計算、すなわち継続は(lambda (a) (* 2 a))となります。だとすれば、現在の継続に限定するなら、プログラマが第一引数のlambda式を書く必要などないはずです。

(* 2 (call-with-continuation-procedure (lambda (* 2 a))
                                       (lambda (cont) (cont (fact 10)))))

と書く代わりに、call-with-continuation-procedure式の返りを待っている続きの計算、つまり(lambda (a) (* 2 a))を自動的に取り出し、 call-with-continuation-procedureの第一引数に渡してもらえれば簡単になります。それが、call-with-current-continuation、いわゆるcall/ccなのです。

つまり、call/ccではこうなります。

(* 2 (call/cc (lambda (cont) (cont (fact 10)))))

contには(lambda (a) (* 2 a))が渡ってくると考えられますね。 fooの素に相当する現在の継続の素を改めて書く必要はなくなりました。

;; call/ccの継続渡し形式への書き換えを試みてみる
(* 2 ((lambda (cont) (cont (fact 10)))
      (lambda (a) (* 2 a))))

しかし、よくよく考えると、(* 2 ...)式の続きの計算はどうなるのでしょう?
厳密に考えれば、read-eval-print-loopがあるはずですから、次のread-eval-printが延々待ってるハズです。これは以降の説明でも重要な点で、無視できないので仕方がありません。 PRINT-AND-NEXT-REPLというものを便宜的に持ち込むことにしましょう。というわけで、次のようにすることにします。

;; call/ccの継続渡し形式への書き換えを試みてみる(PRINT-AND-NEXT-REPL導入版)
(* 2 ((lambda (cont) (cont (fact 10)))
      (lambda (a) (PRINT-AND-NEXT-REPL (* 2 a)))))

call/cc式の外側にある2倍を行う処理もそのまま残留しています。もし、

;; 継続渡し形式への変換と混同しちゃった版
((lambda (cont) (cont (fact 10)))
 (lambda (a) (PRINT-AND-NEXT-REPL (* 2 a))))

という風な継続渡し形式への変換を予想された方は注意してください。 call/ccは継続渡し形式に変換する関数ではなく、あくまで、call/cc式自身の継続(自分の値を待っている計算)を自動的に作り、それをcall/ccの引数であるprocedureに渡して、そのprocedureをcallするという関数です。 (分からなくなったら、call-with-input-fileに戻ってください。入力ポートの生成が継続の生成に置き換わっただけです。)

contに(lambda (a) (PRINT-AND-NEXT-REPL (* 2 a)))を束縛して適用すれば、

(* 2 ((lambda (a) (PRINT-AND-NEXT-REPL (* 2 a))) (fact 10)))

となり、さらに評価すれば以下の様になります。

(* 2 (PRINT-AND-NEXT-REPL (* 2 (fact 10))))

この処理は(* 2 (fact 10))の結果を印字したら次のread-eval-print-loopに行きます。一番外の2倍をする処理は行われません。もし、PRINT-AND-NEXT-REPLが無ければ、処理されてしまい結果は違ってきます。継続渡し形式への変換では導入してなかったものを、このタイミングで導入した理由が分かってもらえたでしょうか。

ここで振り返ってもらいたいのですが、決っしてcall/cc式自体は勝手にジャンプしたり、妙な制御構文になっていたりしていないのです。他のcall-with系の関数となんら変わらない評価をおこなっています。
ただ、callされた手続きに継続が渡ってきて、その継続が手続きとして使われたら、 (そう、使わなくたって一向に構わないってことに注意しましょう。使われなければ、call/cc式は単に値を返すだけです。それはcall-with-input-fileなど他の全ての関数となんら変わりません。) その継続の呼び出しによりジャンプするように見えるかもしれません。しかし、それだってcall/ccに限った話ではなく、他の関数を呼び出すところでは常に起こっていることなのです。 call/cc式自体はどこにもジャンプなどしません。

今度はその渡ってきた継続を使わない例で動作を追ってみましょう。

(+ 1 (call/cc (lambda (cont) 2)) 3)

この式でcontは(lambda (a) (PRINT-AND-NEXT-REPL (+ 1 a 3)))になります。 call/cc式はこの継続を渡して(lambda (cont) 2)をcallします。

(+ 1 ((lambda (cont) 2) (lambda (a) (PRINT-AND-NEXT-REPL (+ 1 a 3)))) 3)

やはり機械的に変換され、contは使われないので

;; 結局、継続を使わなかった
(+ 1 ((lambda (_) 2) _) 3)

となり、結果としては(+ 1 2 3)から6が返ります。

評価順序と継続

継続を保存しておいて、あとからその継続を呼び出すまでの間に、環境の中の値を書き換えた場合はどうなるのでしょうか?
継続がなんとなく分かってくると、今度はそういう疑問を持つようになるようです。

結論から言えば、当然環境の値が変わってれば変わっていますし、その環境のどこにも過去の値の履歴なんかは残っていません。 [[Gauche]]の様にCLOS系のオブジェクトシステムを持つ処理系で、オブジェクトのスロット値を書き換えた場合も当然同じです。

しかし、(変更前の)過去の値が取得できたんだけどなぁ? と首を捻るような経験をした人もいるでしょう。
その謎を解くには、今まで説明してきた評価の流れをもう少し注意深く考えて修正する必要があります。

;; 環境破壊実験の準備

(define k #f)  ;; 継続保存用

(define x 1)   ;; (大域)環境に定義

(+ x (call/cc (lambda (cont) (set! k cont) 2)) 3)

ここでcontに渡る継続はどう表現されるものになるでしょうか? ここまでの話についてこれた方なら機械的に変換してほとんど即答できますね。 (lambda (a) (PRINT-AND-NEXT-REPL (+ x a 3)))です。 (当然kにも同じ継続が保存されています)
保存した継続はこんな風に使えます。

;; まず動作確認
(k 2) => (+ 1 2 3) => 6
(k 20) => (+ 1 20 3) => 24

kが(lambda (a) (PRINT-AND-NEXT-REPL (+ x a 3)))なのですからこの評価結果は理解できますね。

では、xの値を書き換えてみましょう。

;; いざ環境破壊
(set! x 10)

さて、準備が出来ました。この状態で(k 2)などとするとどうなるでしょう?

;; 環境破壊の影響を観測してみる
(k 2)

実は結果は処理系によって違うかもしれないのですが、現在の[[Gauche]]では6になります。

ちょっと奇妙な現象ですね。これは(+ 1 2 3)の結果です。つまり、xの値は書き換え前の値1のままで、なんだか過去に戻ったかの様な錯覚に陥いります。この経験がおそらく最初の疑問になるのでしょう。

ではもう少し変更して、振る舞い調べてみましょう。

;; 環境破壊実験の準備2
(define k #f)  ;; 継続保存用

(define x 1)   ;; (大域)環境に定義
(define z 3)   ;; (大域)環境に定義

(+ x (call/cc (lambda (cont) (set! k cont) 2)) z)

この後で、今度はxとzを変更してみることにします。

;; 環境破壊
(set! x 10)
(set! z 30)

これならどうでしょう?

;; 環境破壊の結果は?
(k 20)

これも結果は処理系によって違ってきますが、現在の[[Gauche]]では51を返します。これは(+ 1 20 30)の結果です。つまり、xは変更前の過去の値が、zは変更後の新しい値が得られていることになります。どうでしょう、これなら分かるのではないでしょうか。

保存した継続kは今までの説明のまま機械的に変換すると、 (lambda (a) (PRINT-AND-NEXT-REPL (+ x a z)))になるはずなのですが、これは正確ではなかったということです。

;; 実は不正確だった継続
(lambda (a) (PRINT-AND-NEXT-REPL (+ x a z)))

正しくは、(今の[[Gauche]]では)継続kは (lambda (a) (PRINT-AND-NEXT-REPL (+ 1 a z)))だったのです。なぜなら、call/cc式を評価する前にxは評価されて1を得ていたからです。

;; より正確な継続
(lambda (a) (PRINT-AND-NEXT-REPL (+ 1 a z)))

つまり、[[Gauche]]では左から順に引数を評価するために、

;; 引数の評価順とcall/ccの位置
;; (1) xが評価される
;; (2) call/cc式が評価される
;; (3) zが評価される
;; (4) +が3つの値に適用される

(+ x call/cc式 z)

のcall/cc式を評価する前に、すでにxの値が環境から取り出されて1になっていて、 call/cc式の継続(続きの計算)には「環境からxの値を取り出す」という計算は含まれてないのです。だから継続kにはxは関係ないし、1がxの値だったということも知らないと思っていいでしょう。逆に「zの値を環境から取り出す」という計算は含まれていますから、継続を呼び出すとその時点でのzの値である30を取り出すわけです。

もっと言えば、(lambda (a) (PRINT-AND-NEXT-REPL (#<subr +> 1 a z)))で、もし、継続を保存後に(set! + *)とか(set! + max)などと変更しても、やはり加算を行ないます。いまや+は#<subr *>や#<subr max>になっているにもかかわらずです。 (つまり、すでに加算を行う気マンマンでcall/cc式の評価に突入してたのです。同じ様に言えば、継続は「1とaとzを加算する気マンマン」なのであって、「xとaとzを+するつもり」だったわけではありません。)

結局環境を書き換えれば、当然変わっているのですが、「環境から値を取り出すという計算」がcall/cc式の評価前に済んでしまっているか、それとも継続(続きの計算)に含まれていて、継続起動後に処理されるかが差を生むだけのことなのです。

当然オブジェクトのスロット値を書き換えている場合も同様です。そのスロットの値を取り出す前にcall/cc式が評価されるのか、それともcall/cc式の継続に含まれるのかが鍵を握ります。

くどいようですが、継続とは続きの計算のことで、重要なのはどの時点の継続かということです。ある時点の続きにはどういう計算が含まれるかを理解せずに継続を使いこなすのは難しいと思ってください。

実は[[Scheme]]では引数の評価順序は未定義なので、そもそも上の例のような場所でcall/ccを使うのは正しくありません。 (実際、処理系によっては違う結果を得てしまった人も居るはずです。これは移植性のないコードを書いていることの証拠です。) しかし、どういう順序でどんな計算が進むかの知識が重要であることは変わりません。

その意味では、[[Scheme]]は比較的評価規則は単純で、演算の優先順位などもないので動作を読みやすくなってます。継続を学ぶにはもってこいの言語なのです。しかし、一旦マクロなどで評価規則が複雑なものを導入して、それと併せて使うと、その動作を予測するのは急に困難になります。

環境を書き換えずに継続を呼んでも、なんら変化の無い計算を繰り返すだけなのであまり意味がありません。
(継続に渡す引数を変えれば、それなりの変化は楽しめますが。)
とすれば、継続を使う局面では環境の書き換えと無縁ではいられませんし、実際処理系が値の書き換えを許している以上は、評価順序に詳しくなければ使いこなせないということになります。 (生成した継続自身を外側の環境に保存したり、新しく生成した継続で書き換えるような環境の変更も良く見かけます。) そう考えると、恐らく複雑な構文や演算子の優先順などがある言語処理系で継続を導入しても、結局誰にも使いこなせずに不要になってしまうかもしれません。

では、練習問題です。次はどうなるか確認してみてください。

;; 環境破壊実験の準備3
(define k #f)  ;; 継続保存用

(define x 1)   ;; 環境に定義

((identity +) x (call/cc (lambda (cont) (set! k cont) 2)) x)

あまり変わっていないですが、

;; 環境破壊
(set! x 10)
(set! + max)

;; さて結果は?
(k 2)

(k 2)を評価したらどうなるでしょう？
(lambda (a) (PRINT-AND-NEXT-REPL (#<subr +> 1 a x)))ですから13?
実は今の[[Gauche]]では (lambda (a) (PRINT-AND-NEXT-REPL ((identity +) 1 a x)))なので10が返ってきます。最初の(identity +)が引数の評価より後なのです。実は+などの様な組込み関数を使わずにユーザ定義関数を使う場合にも最後に評価されます。というか、むしろ実際には逆で組込み関数の場合に最適化のために引数が評価されるより前に#<subr +>に評価済みになっているのです。なお、この挙動は-fno-inlineオプションを付けてgoshを起動しても変わってきます。

継続は続きの計算です。ならば、続きの計算が何であるかを知ることが継続を使いこなす上での必須のスキルと言って良いでしょう。仮に[[Scheme]]で継続を使いこなせても、別の言語処理系の上で使いこなすには、その言語の評価順などの知識が必要になります。もちろん継続についての理解はどこに行っても通用するので学ぶことは意義があります。

call/ccパズル

call/ccパズルというものがあります。以前comp.lang.schemeというニュースグループで話題になったプログラムです。このコードが何をするかを予想してみろ、というのですがそう簡単ではありません。

;; call/ccパズルお題
(let* ((yin ((lambda (foo) (newline) foo)
             (call/cc (lambda (bar) bar))))
       (yang ((lambda (foo) (write-char #\*) foo)
              (call/cc (lambda (bar) bar)))))
  (yin yang))

しかし、このパズルの動作を理解するのはちょっとした自信にもなると思いますのでここでは少し説明してみることにします。

まずコードの本質的な部分を剥き出しにするために少しだけ簡略化しましょう。

2行目の(lambda (bar) bar)はcall/ccが自動的に作成した継続をそのまま返しています。いわゆるidentityという関数です。それが、1行目のlambda式のfooに束縛され、ここでもそのままfooが返されています。最終的には、それがyinに束縛されます。
つまりyinにはcall/ccが作成した継続が束縛されます。従って((lambda (foo) (newline) foo) (call/cc (lambda (bar) bar)))の部分は (call/cc identity)と置き換えても動作そのものは変わりません。なぜわざわざこんなややこしいことをしているかと言うと、一種のデバッグプリントのためです。

つまり、このcall/ccで作成した継続がどこかで(あるいはどこであれ) callされると(newline)を通過するので、改行が表示されることで継続が起動された瞬間が目に見えるわけです。このことは、

;; 最初の束縛部分に注目
(EXTERNAL-EXPR ((lambda (foo) (newline) foo) (call/cc (lambda (bar) bar))))

で、call/ccが作成する継続が、

;; 最初のcall/cc式の継続
(lambda (a)
  (EXTERNAL-EXPR ((lambda (foo) (newline) foo) a)))

となることからも分かります。見ての通り(newline)が続きの計算に含まれています。

同じ様にyangの方も4行目のcall/ccで作成された継続がcallされると '*'という文字が印字されることで継続が起動されたことを教えてくれます。

これは継続が起動された瞬間が見えるので、 call/cc(に限らず大抵の式)のデバッグに使える一般的な手法です。是非覚えておきましょう。
(もちろんcall/cc式が素直に値を返した場合にも通過します。) ともかく、ここを省略するとコードは少し簡単になって次の様になります。

;; STEP 0
(let* ((yin (call/cc identity))
       (yang (call/cc identity)))
  (yin yang))

これならなんとか全体が見通せるでしょう。

ポイントは、let*のローカル束縛の評価順序です。
yinに束縛される継続l#<continuation yin>は

;; #<continuation yin>
(lambda (a)
  (PRINT-AND-NEXT-REPL
   (let* ((yin a)
          (yang (call/cc identity)))
     (yin yang))))

一方yangに束縛される継続#<continuation yang>は不正確ですが、

;; #<continuation yang>っぽいもの
(lambda (a)
  (PRINT-AND-NEXT-REPL
   (let* ((yin #<continuation yin>)
          (yang a))
     (yin yang))))

正しくするなら、ちょっと形が変わってしまうが仕方がありません。

;; #<continuation yang>
(lambda (a)
  (PRINT-AND-NEXT-REPL
   (let ((yang a))
     (#<continuation yin> yang))))

こうなると思って良さそうです。

yinに束縛される継続には「新たに継続を作成してyangに束縛するという計算」が含まれていますが、 yangに束縛される継続ではyinはすでに無く、作成済みの継続が見えます。その意味でyinとyangは対等ではありません。
この立場の違いは、そのまま評価順序からきています。

では、(yin yang)を評価してみましょう。おっと、その前に確認しておきます。そもそも、ここに至るまでに、yinのためのcall/ccが評価されるので、この段階で改行が一発入ります。 yangのためのcall/ccも評価されるので、*が一発入っているのでお忘れなく。

;; ここまでの結果

*I

では、気を取り直して(yin yang)の評価です。

;; STEP 1
(#<continuation yin> #<continuation yan>)

では、#<continuation yin>だけ上記の継続手続きで置き換えてみると次式になります。

;; STEP 1'
((lambda (a)
   (PRINT-AND-NEXT-REPL
    (let* ((yin a)
           (yang (call/cc identity)))
      (yin yang))))
 #<continuation yang>)

では適用してみましょう。

;; STEP 2
(PRINT-AND-NEXT-REPL
 (let* ((yin #<continuation yang>)
        (yang (call/cc identity)))
   (yin yang)))

今度はこの評価をすることになります。 yinには先程と同じ#<continuation yang>が束縛されます。 #<continuation yin>ではないので注意してください。そして、#<continuation yang>がyinに束縛される所で、改行が入ります。元コードでは、((lambda (a) (newline) a) #<continuation yang>)だからです。

;; ここまでの結果

*
I

次は、call/cc式が評価されて新たな継続#<continuation yang'>が得られます。新たに作られるので'(ダッシュ)を付けておきました。区別さえできるなら、インデックスを振っても良いでしょう。ともあれ、call/cc式が評価された直後はこうなります。

;; STEP 3
(PRINT-AND-NEXT-REPL
 (let ((yang #<continuation yang'>))
   (#<continuation yang> yang)))

元々のコードで言えば、yangに束縛される時点で*が表示されるはずです。

;; ここまでの結果

*
*I

#<continuation yang'>を継続手続き風に書くとどうなるでしょう?

;; #<continuation yang'>っぽいもの
(lambda (a)
  (PRINT-AND-NEXT-REPL
   (let* ((yin #<continuation yang>)
          (yang a))
     (yin yang))))

正確には、

;; #<continuation yang'>っぽいもの
(lambda (a)
  (PRINT-AND-NEXT-REPL
   (let ((yang a))
     (#<continuation yang> yang))))

では、(yin yang)を評価します。

;; STEP 4
(#<continuation yang> #<continuation yang'>)

#<continuation yang>を継続手続き風の式で置き換えます。

;; STEP 4'
((lambda (a)
   (PRINT-AND-NEXT-REPL
    (let ((yang a))
      (#<continuation yin> yang))))
 #<continuation yang'>)

これを適用すると、

;; STEP 5
(PRINT-AND-NEXT-REPL
 (let ((yang #<continuation yang'>))
   (#<continuation yin> yang')))

今度はyangには#<continuation yang>が束縛されますが、ここで*が入ります。

;; ここまでの結果

*
**I

すると、次に評価すべき式は

;; STEP 6
(#<continuation yin> #<continuation yang'>)

となり、同様に#<continuation yin>を継続手続き風の式に置き換えると、

;; STEP 6'
((lambda (a)
   (PRINT-AND-NEXT-REPL
    (let* ((yin a)
           (yang (call/cc identity)))
      (yin yang))))
 #<continuation yang'>)

適用すれば、

;; STEP 7
(PRINT-AND-NEXT-REPL
 (let* ((yin #<continuation yang'>)
        (yang (call/cc identity)))
   (yin yang)))

ここで、yinに束縛される瞬間改行が入り、さらに新たな継続#<continuatiogn yang''>を生成してyangに束縛するところで *が入ります。

;; ここまでの結果

*
**
*I

では、引き続き評価しましょう。

;; STEP 8
(#<continuation yang'> #<continuation yang''>)

繰り返しで、だいぶ退屈してきたかもしれないが続けます。

;; STEP 8'
((lambda (a)
  (PRINT-AND-NEXT-REPL
   (let ((yang a))
     (#<continuation yang> yang))))
 #<continuagion yang''>)

適用すると、

;; STEP 9
(PRINT-AND-NEXT-REPL
 (let ((yang #<continuagion yang''>))
   (#<continuation yang> yang)))

yangに継続が束縛されるところで*が入ります。

;; ここまでの結果

*
**
**I

次はこの式の評価です。

;; STEP 10
(#<continuagion yang> #<continuation yang''>)

#<continuagion yang>を継続手続き風の式で置換すると、

;; STEP 10'
((lambda (a)
  (PRINT-AND-NEXT-REPL
   (let ((yang a))
     (#<continuation yin> yang))))
 #<continuation yang''>)

適用すると、

;; STEP 11
(PRINT-AND-NEXT-REPL
 (let ((yang #<continuation yang''>))
   (#<continuation yin> yang)))

yangに束縛されるところで、'*が入ります。

;; ここまでの結果

*
**
***I

そして、再び、#<continuation yin>のcallになる。ということは改行が期待できますね。

;; STEP 12
(#<continuation yin> #<continuation yang''>)

置き換えると、

;; STEP 12'
((lambda (a)
  (PRINT-AND-NEXT-REPL
   (let* ((yin a)
          (yang (call/cc identity)))
     (yin yang))))
 #<continuation yang''>)

適用すると、

;; STEP 13
(PRINT-AND-NEXT-REPL
 (let* ((yin #<continuation yang''>)
        (yang (call/cc identity)))
   (yin yang)))

yinに束縛されるところで、改行が入り、 call/cc式を評価して新たな継続#<continuation yang'''>が作成され、 yangに束縛されると、*が入ります。ここまでで打ち止めとしましょう。

;; ここまでの結果

*
**
***
*I

このまま続ければ、一行毎に*の数が一個ずつ増加していくのが確認できます。改行はyinへの束縛が起こった瞬間であり、*はyangへの束縛が起こった瞬間です。上記の結果は、まさにそのデバッグプリントなのです。

;; STEP 0 (再掲)
(let* ((yin (call/cc identity))    ;; call/cc-yin式
       (yang (call/cc identity)))  ;; call/cc-yang式
  (yin yang))

印字出力を見落とさないように動作を追うのは大変ですが、是非一度手を動かしてやってみてください。ポイントは、次の点でしょうか。

改行や*が印字されるのは継続が束縛されるタイミングである。(デバッグプリント)
最初のcall/cc-yin式はただ一度だけ評価され、#<continuation yin>を生成し、あとは同じ継続が使い回される。
次のcall/cc-yang式は#<continuation yin>がcallされた時にのみ、評価されて新しい継続を生成する。

では、(yin yang)のトレースをまとめて眺めてみましょう。

;; STEP 1
(#<continuation yin> #<continuation yang>)
;; STEP 4
(#<continuation yang> #<continuation yang'>)
;; STEP 6
(#<continuation yin> #<continuation yang'>)
;; STEP 8
(#<continuation yang'> #<continuation yang''>)
;; STEP 10
(#<continuagion yang> #<continuation yang''>)
;; STEP 12
(#<continuation yin> #<continuation yang''>)
;;
(#<continuation yang''> #<continuation yang'''>)
;;
(#<continuation yang'> #<continuation yang'''>)
;;
(#<continuation yang> #<continuation yang'''>)
;;
(#<continuation yin> #<continuation yang'''>)
;;
(#<continuation yang'''> #<continuation yang''''>)
;;
(#<continuation yang''> #<continuation yang''''>)
;;
(#<continuation yang'> #<continuation yang''''>)
;;
(#<continuation yang> #<continuation yang''''>)
;;
(#<continuation yin> #<continuation yang''''>)

じっと見て規則性を確認してください。 #<continuation yin>が出てきたらlet*の最初の束縛から呼ばれるところで、改行が印字されます。後は、#<continuation yang>や#<continuation yang'>などが束縛される回数だけ*が印字されます。

面倒かもしれませんが、是非一度は手を動かして動作を追ってみて下さい。

お手元マルチスレッド

ちょっと継続を使って遊んでみましょう。これを通して継続の力の一端に触れた気になっていただければ嬉しいです。

まずはファイルから一行読み込むだけのプログラムから始めることにします。

;; サンプルファイルから一行読み込む
(let ((in (open-input-file "sample.txt")))
  (read-line in))

これを少し改造してみます。

(define k #f)  ;; 継続保存用

(let ((in (open-input-file "sample.txt")))
  (read-line (call/cc (lambda (cont)
                        (set! k cont)
                        in))))

call/cc式はkに継続を保存しますが、その継続cont自体は使わずに、inだけを返します。つまり、最初のコードと動作は変わりません。

;; 保存された継続
(lambda (a)
  (PRINT-AND-NEXT-REPL
   (let ((in #<inport>))
     (read-line a))))

保存された継続はこんな風になるでしょう。正確にはinに束縛するところはすでに完了していますし、 [[Gauche]]ならread-lineも評価済みなので、次式のようになっています。

;; 保存された継続
(lambda (a)
  (PRINT-AND-NEXT-REPL
     (#<subr read-line> a)))

さて、ここで継続を保存しておいたので、いつでもサンプルファイルから一行読み込むという処理が呼び出せます。プロンプトから(k in)を何度か呼ぶと次々に行が返されるはずです。

途中で(k in)以外の式を評価しても問題ありません。そんなの当然じゃないか?と思われれば、あなたはすっかり継続に馴染んでいます。しかし、良く良く考えると、これは結構スゴいことです。プログラマが手動でスレッド切り換えをしているようなものですからね。

では、もう少しその雰囲気を味わっていただきましょう。

;;----------------------------------------
;;                準備
;;----------------------------------------
;; バッファの用意
(define buf "")
;; 読み込み処理の継続保存用
(define kin #f)
;; 書き出し処理の継続保存用
(define kout #f)

;; 入力ポート保存用
(define inp #f)
;; 別の入力ポート
(define in2 (open-input-file "Another-in.txt"))

;; 出力ポート保存用
(define outp #f)
;; 別の出力ポート
(define out2 (open-output-file "sample-out2.txt"))

;; 読み込みのための継続捕捉
(let* ((in (open-input-file "Continuation.txt"))
       (line (read-line (call/cc (lambda (cont)
                                   (set! inp in)
                                   (set! kin cont)
                                   in)))))
  (set! buf (string-append buf "\n" line)))

;; 書き出しのための継続捕捉
(let ((out (call/cc (lambda (cont)
                      (let ((out (open-output-file "sample-out.txt")))
                        (set! outp out)
                        (set! kout cont)
                        out)))))
  (display buf out)
  (flush out)
  (set! buf "")
  (display "write and buf clear."))

;;----------------------------------------
;;                評価
;;----------------------------------------
;; (1) 読み込みを何度か適当に評価して
(kin inp)

;; (2) たまに気が向いたら書き出ししよう
(kout outp)

;; (3) さらにたまに気が向いたら別のポートを読み込めばファイルのマージもできる
(kin in2)

;; (4) さらにたまに気が向いたら別のポートに書き出せはファイルの分割もできる
(kout out2)

最初の方の準備が済んだら、(1)(2)(3)(4)を適当な順序で複数回実行してみてください。作業した順でファイルを(行単位でですが)マージしたり分割したりできるようになりました。そしてたまに(kout outp)とか(kout out2)とするとバッファリングした情報を書き出せているので、そのタイミングで sample-out.txtやsample-out2.txtを確認しながら評価してみてください。
これはタスクの切り換えを自分でやっていると思えば、ごくごく当たり前の結果なんですが、 継続は保存してから呼び出されるまでの間、完全に休眠しており、 その間にいかなる式の評価でもはさむことが出来ます。
そして、kinやkoutなどの継続を起動すると、あたかもずっとそれをやっていたかの様に続きの計算を粛々と行うのです。

すでに、手動でのスレッド切替は体感できたと思いますので、キューを用意しておき、(lambda () (kin inp))などをキューイングして、順次デキューして評価したり、新たに(lambda () (kout outp))などを生成してエンキューすれば、マルチスレッドもどきは簡単に作れてしまいます。スケジューリングの実験も手軽にできると思うので、どんどんコードを書き換えて試してみてください。

これが、いかなる制御構造の実現も可能にする継続の力です。

ストリーム

Sat, 07 Apr 2007 23:09:52 +0900

ストリームは遅延評価のためのデータ構造です。ストリームは遅延リストとも呼ばれることがあります。

遅延評価とは必要になったときだけ計算するという意味です。必要になったときだけ計算できれば、無限の長さのデータ構造すらも扱うことができます。

Gaucheではutil.streamライブラリで遅延評価を実現しています。

 gosh> (use util.stream)
 #<undef>

util.streamライブラリを使うために、あからかじめ式(use util.stream)を評価させておきます。

 gosh> (define fib (stream-cons 0 (stream-cons 1 (stream-map + fib (stream-cdr  fib)))))
 fib

この例はフィボナッチ数列と呼ばれる無限の数列を定義しています。

stream-cons手続きは、リストに対するcons手続きと同様にストリーム(遅延リスト)構造を構築します。

stream-carとstream-cdrはcar手続き、cdr手続きと同様に、ストリームから要素の値を取り出します。

stream-map手続きは、リストに対するmap手続きと同様にすべての要素に手続き適用を行います。上記の例では停止条件なしにfibを再帰的に呼び出しています。したがってfibは無限リストを形成します。

 gosh> (stream->list (stream-take fib 10))
 (0 1 1 2 3 5 8 13 21 34)

stream-take手続きはストリームからある個数だけ要素を取り出します。 stream->list手続きはストリームをリストに変換します。

 gosh> (stream-ref fib 10000)
 33644764876431783266621612005107543310302148460680063906564769974680081442166662368155595513633734025582065332680836159373734790483865268263040892463056431887354544369559827491606602099884183933864652731300088830269235673613135117579297437854413752130520504347701602264758318906527890855154366159582987279682987510631200575428783453215515103870818298969791613127856265033195487140214287532698187962046936097879900350962302291026368131493195275630227837628441540360584402572114334961180023091208287046088923962328835461505776583271252546093591128203925285393434620904245248929403901706233888991085841065183173360437470737908552631764325733993712871937587746897479926305837065742830161637408969178426378624212835258112820516370298089332099905707920064367426202389783111470054074998459250360633560933883831923386783056136435351892133279732908133732642652633989763922723407882928177953580570993691049175470808931841056146322338217465637321248226383092103297701648054726243842374862411453093812206564914032751086643394517512161526545361333111314042436854805106765843493523836959653428071768775328348234345557366719731392746273629108210679280784718035329131176778924659089938635459327894523777674406192240337638674004021330343297496902028328145933418826817683893072003634795623117103101291953169794607632737589253530772552375943788434504067715555779056450443016640119462580972216729758615026968443146952034614932291105970676243268515992834709891284706740862008587135016260312071903172086094081298321581077282076353186624611278245537208532365305775956430072517744315051539600905168603220349163222640885248852433158051534849622434848299380905070483482449327453732624567755879089187190803662058009594743150052402532709746995318770724376825907419939632265984147498193609285223945039707165443156421328157688908058783183404917434556270520223564846495196112460268313970975069382648706613264507665074611512677522748621598642530711298441182622661057163515069260029861704945425047491378115154139941550671256271197133252763631939606902895650288268608362241082050562430701794976171121233066073310059947366875

上記の例ではstream-ref手続きで任意の位置にある要素の値を取り出しています。

ストリームは、たとえば要素を何個用意すれば良いかが事前に分からなくても気にせずプログラミングすることができます。

 gosh> (stream->list (stream-take-while (lambda (x) (< x 1000)) fib))
 (0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987)

上記は個数ではなく、ある数未満の数列を得る例です。 stream-take-whileは、ある条件が真のあいだだけ要素を取り出します。ここでは無名手続き(lambda (x) (< x 1000))で要素を判定させ、 1000未満の要素だけを取り出しています。

ストリームは、必要になったときに必要な数だけ計算すれば良いので効率的です。