できる 盥回し
taraiが実行できるようになった。wikipediaの定義( http://ja.wikipedia.org/wiki/%E7%AB%B9%E5%86%85%E9%96%A2%E6%95%B0 )から、
(define (tarai x y z) (if (<= x y) y (tarai (tarai (- x 1) y z) (tarai (- y 1) z x) (tarai (- z 1) x y))))
こういうやつ。
1ファイルで済ませるのはここまでで、後は個々の定義ごとにファイルを分解するなどする。
とりあえず、すべてのOPをdefine-syntaxを使って分離した。次回はいよいよC言語への変換。そのまえにファイル入出力か。
末尾再帰最適化くらい入れる必要があるかもしれないけど、現段階でも使われない継続は(たぶん)GCに回収されるので優先度低い。セグメントに分割してGC領域を常識的なサイズに絞る必要性はあるかもしれない。
drySchemeのめざすところ
drySchemeは純粋に研究用の実装なので、drySchemeがRnRSになるとか高速になるとかコンパイラを導入するとかは予定していない。
drySchemeの用途は、
- パケットフォーマット定義をコンパイルするためにLLVMまたはCOINSのIRに変換する
- 変換したIRをLLVMやCOINS、gccに渡す
- コンパイラから返却されたデータのリンクとPU(Cellの場合SPE)への配置
- イベントチャンネルの観察と中継
というもので、この程度の仕事ならたしかにschemeは実装コストに見合う効果が(Cのベタで書くよりも)見込まれる。現段階では「Cellで動くか動かないか」だけが重要な視点で、ベンチマークの段階では最適化したCのコードに置き換えられる運命にある。
実用段階、すなわち、実際のScheme処理系に組み込んで使用するのはあまり簡単ではない。通常のSchemeにはパケットを効率的に処理するためのフレームワークが無く、GCを制御することも出来ない*1。