遅延評価の話

遅延評価の話 - SiroKuro Page に関して http://d.hatena.ne.jp/nagaShima/20090127/p3 からツッコミ受けたのでその返答。
最初に断っておきますが、『自分が kuzha に遅延評価を入れるかどうか考えてみる』 という立場で話してあります。Phine に遅延評価を入れることには別に反対していたりしません。
遅延評価って、あると便利な部分もあるんです。が、結果的にプログラム全体で積極的に活用できるだけの汎用性があるかと言われたらそうでもないよなぁと思ってしまうのです。これが逆に Haskell みたいに「ぜんぶ遅延です」ってことになると「活用せざるを得ない」という事態になってそれはそれで問題ないのですが、先行評価と遅延評価を任意に選択できるとなればプログラム内の大部分を占めるのは先行評価で、遅延評価はおまけになっちゃうよなぁという思想を持っています。
nagaShima さんが例に挙げた SQL の発行については 「それ Future パターンで十分じゃない？」 という考えだったりします。ライブラリの問題はライブラリで解決されるべきであって、言語内に取り込んでもらうだけのパワーは遅延評価にはないなぁと思っています。
ちなみに Actor-Future ベースの簡易分散環境構築ライブラリは、kuzha にも導入することを検討しています。現在仕様をまとめてる最中です。他の言語とも繋がるようにコンパクトな仕様を心がけています。分散しての GC が面倒ですが、そこを解決したら実装に移ります。

ちなみに non strictness な関数というのは、ぶっちゃけて言えば『関数の引数を計算すると無限ループになるけど、関数呼び出し自体は無限ループにならずに計算できるよ』 という性質を持った関数のことです。例えば遅延評価がある Haskell では次のような式は無限ループに陥らず値を返します。

let foo x = 1
    bar x = bar x
in  foo (bar 1)

一方、次のようなＣの関数は、無限ループに陥ります。

foo(x) { return 1; }
bar(x) { return bar(x); }
main() { foo(bar(1)); }

これが non strictness な関数を認める処理系と、そうでない処理系の違いです。