SASADA Koichi <ko1 atdot.net> writes:

> 　すみません，お二方が「こっちのほうがいい」と言っているのに，
> さっぱりその利点がわかりません．何か前提が違う気もするんです
> が．教えていただけませんか．

まず、前の記事で書き間違いがありましたので訂正しておきます。

> > |(2)を許すんなら、(1)も(2)も同じように処理するのが良いのではと思います。
> > |
> > |暗黙の引数で受けとるかどうか、呼び出し側では分からないですよね。
> > |呼び出す側で必要な時だけProcを作るとしても、ブロックが渡されてくるか、
     ^^^^^^^^^^「呼び出される側」の間違いです。
> > |Procが渡されてくるか、呼ばれる側では分からないので、「つねに一人前の
> > |Procが渡されてくる」で良いんでは。

ささださんが意図している最適化は、
・呼び出し側がProc.newを使わず { ... } を渡し、
・かつ、呼び出される側が暗黙の引数で受けとった時に、
一人前のProcを割り当てずに軽いもの(Lispの世界だとeasy closureとか呼ん
だりする)だけ作って済まそうというものだと思います。

呼び出される側は、FullProcとEasyProcを区別せずにyieldできるのでしょう
か?  もし区別が必要だとすると、iterator側では両方のコードを用意するの
でしょうか、それともどちらかにcanonicalizeするのでしょうか?

どうせ多くの場合FullProcにcanonicalizeすることになるんじゃないか、だと
したらEasyProc なんて用意する意味はないんじゃないか、という意図です。

また、「EasyProcを作って渡したけれど、呼び出された側は名前のある引数で
受けとった」とすると、それをチェックしてFullProcに変換しなければなりま
せんよね。最初から何も考えずにFullProcを作る場合よりオーバーヘッドがか
かります。

いずれにせよ、EasyProcを作るなんていう最適化は完全にoptionalですから、
後回しにして良いんではないかと思います。

				前田敦司

--
ML: yarv-dev quickml.atdot.net
使い方: http://www.atdot.net/~ko1/quickml