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

えぐち です。

----------
> 差出人 : Yukihiro Matsumoto <[e-mail]>
> 件名 : [ruby-dev:566] Re: [563] Tail recursion (Re: optimize (...))
> 
> まつもと ゆきひろです
> 
> In message "[ruby-dev:565] Re:[563] Tail recursion (Re: optimize (...))"
>     on 97/09/29, "EGUCHI Osamu" <[e-mail]> writes:
> 
> |えぐち です。
> 

> |いまフレーム・ブロック・スコープなど環境をハードウェアスタックに
> |つんでいますが、これを動的な配列なり、リストなりに置くようにする
> |事で fact な問題は緩和されそうです。
> 
> ええ，それはそうなんですけど，やっぱりハードウェアスタックは
> 速いので，なかなか迷うところです．以前，ソフトウェアスタック
> 化を実装してみたところ，かなり遅くなりましたし．
> 
> # ずいぶん前なので数値を忘れてしまったのですが．

このへんのバランスからして今の rb_eval() は
かなりの完成度にあると思うです。

> |しかし真剣に rb_eval() を非再帰構造にするとなると、 
> |break/redo/next ３兄弟が制御構造 *ではなく* 関数であることや、
> |例外・イテレータとの折り合いを付けるために、字句・構文・評価で
> |情報の受け渡しを密接に行わなければならないのでかなり厄介です。
> 
> この辺を考えて1.1ではbreak/next/redo/retryは制御構造になって
> ます．でも，問題はそれだけではありませんものね．

でもかなり parse で出来ることが増えます。
欠点としては、Obfuscated ruby code contest で

	break = next + redo / retry

が選外になることがあげられます。 (^^)

> |私のイメージでは、rb_eval() を非再帰化するというと、
> |構文木を今の異種リストから機械語の様なバイトコードに変更する
> |と言うことのように思えるのですが、違いますか？
> 
> そこまでは考えていないんですけど，
> 
>    case NODE_WHILE:
>      while (eval(node->cond)) {
>        eval(node->body);
>    }
> 
> のようになっているものを
> 
>    case NODE_JUMPIF:
>      if (RTEST(result)) {
>        node = node->jump;
>        goto again;
>      }
>      break;
> 
> のようなものによって展開できたら良いなあ，と考えているのです．

この方法でのパーサは、 break, next, redo などの行き先も
（たぶん２パスで）生成することが必要になりますね。
rb_eval() がその分実行時のダイナミックなフロー制御から開放され
かなりループなどの実行が速くなりそうです。

	えぐち