[ruby-dev:584] Re: Tail recursion (Re: optimize (...))

えぐち です

----------
> 差出人 : Yukihiro Matsumoto <[e-mail]>
> 件名 : [ruby-dev:574] Re: Tail recursion (Re: optimize (...))
> 
> まつもと ゆきひろです
> 
> In message "[ruby-dev:570] Re: Tail recursion (Re: optimize (...))"
>     on 97/09/30, "EGUCHI Osamu" <[e-mail]> writes:
> 
> |えぐち です。
> 
> |このへんのバランスからして今の rb_eval() は
> |かなりの完成度にあると思うです。
> 
> いきあたりばったりの産物なんでそういわれると恥ずかしいです．

いきあたりばったりで、ここにたどり着く人のセンスってすごいですね。
＃私は、速度上げようとかの煩悩ですぐ醜悪なコードにしちゃう。
＃それっぽく思ったらマージを却下してください。

> |この方法でのパーサは、 break, next, redo などの行き先も
> |（たぶん２パスで）生成することが必要になりますね。
> 
> 飛び先を保持する手法はいくつもありますから，2パスは必要ない
> と思います．gotoはないんで，飛び先はあらかじめ決められますし
> ね．

そうですね、私も真っ先に、、２パスでないとだめかな、、
と思っては見たものの、これではコンパイル時間が長くなって
何の為にやるのかわかんなくなってしまいます。

バイトコードをファイル化するならいくらでもコンパイルに
時を裂けますけど。。。

>     とはいえ，ゆうべつらつらと考えてたんですが，イテレータと
> の絡みがあったりして，ことはそうは簡単ではないようです．ちゃ
> んと仮想機械(もどき)を設計しないと動かないみたい．

イテレータブロック中の break や next が有効ってことですか？
そーなんだろなやっぱり、、難問過ぎ！

入れ子のイテレータから例外で脱出する場合も厳しいですね。
（いまは例外もループ構造も setjmp だからいいけど）

＃仮想 と もどき がいっしょに出てくると、いかがわしいですが（笑）
結局、rb_eval() から再帰を追い出すとバイトコードインタープリタ
の様な形に近づいていくようですね、仮想マシンかなぁ、、
たぶんこれは必然だとおもいます。

もちろん、今の eval.c に改良を与えて幾つかの問題を解決することは
出来ますので、短期的にはその方が幸せなような、、

	えぐち