第14章コンテキスト

本章の範囲は随分と広い。まず最初に評価器の内部状態がどうやって表現されているかという話をする。その後、その実例としてクラス定義文でのその状態の変化を読む。続いて内部状態がメソッド定義文にどう影響を与えるかを見る。最後に、その双方によって変数の定義と参照の挙動が変わる様子を観察していく。

Rubyスタック

コンテキストとスタック

典型的な手続き型言語のイメージだと、手続き呼び出しのたびに、ローカル変数領域や戻る場所など手続き一つの実行のために必要な情報を構造体（スタックフレーム）に格納し、それをスタックに積む。手続きから戻るとスタックの先頭の構造体がポップされて前のメソッドに戻る。例えば第5章『ガ－ベージコレクション』で解説した Cプログラムの実行イメージはそれにピッタリ当てはまる。

ここで注意したいのは、プログラムの実行中に変わるのはスタックだけで、プログラムのほうは場所によって変わったりしないことだ。例えば「ローカル変数iの参照」なら、「いまのフレームのiをください」という命令があるだけで、「このフレームのiをください」とは書かない。つまりスタックの状態「だけ」によって結果が変わってくるわけである。だからこそ手続きがどんなときに何回呼ばれようとも、そのコードは一つだけで済む（図1）。

(stack)
図1: 変わるのはスタックだけ

Rubyの実行も基本的にはメソッドつまり手続きの呼び出しの連鎖に他ならないから、本質的にはこれと同じ実行イメージを持っている。つまりコードは同じで、アクセスされる側のローカル変数スコープやブロックローカル変数スコープのほうが変化する。そしてそういうスコープはスタックで表現される。

ただしRubyではイテレータやProcを使うと以前に使ったスコープに一時的に戻れたりするからスタックの単純なプッシュ・ポップだけでは実装できない。そのためRubyスタックは実行中に複雑に積み変えられる。だからいちおうスタックとは言ってはいるが単なるリストと考えたほうがいいかもしれない。

またメソッド呼び出し以外にクラス定義でもローカル変数スコープが変わったりするので、メソッド呼び出しとローカル変数スコープの遷移が一致しない。他にブロックもあるのでそれも分割しないといけない。そんなこんなで理由がいろいろあって、スタックはなんと七本もある。

スタックポインタ	スタックフレーム型	説明
`ruby_frame`	`struct FRAME`	メソッド呼び出し記録
`ruby_scope`	`struct SCOPE`	ローカル変数スコープ
`ruby_block`	`struct BLOCK`	ブロックスコープ
`ruby_iter`	`struct iter`	現在の`FRAME`がイテレータか
`ruby_dyna_vars`	`struct Varmap`	ブロックローカル変数スコープ
`ruby_class`	`VALUE`	メソッド定義先クラス
`ruby_cref`	`NODE`（`NODE_CREF`）	クラスのネスト情報

Cはスタック一本でRubyが七本ということは、単純計算するとRubyの実行イメージはCより七倍は手強いはずである。だが実際には七倍なんてことは全くなくて、Rubyのほうが二十倍は手強い。

ではまずこれらのスタックと、そのスタックフレーム（である）構造体について簡単に解説していこう。定義されているファイルはeval.cかenv.hだ。基本的にはこれらのスタックフレームをさわるのはeval.cだけ……にしたいわけだが、 gc.cでマークするときに構造体型を知る必要があるためenv.hに出されているものもある。

もちろんマークするのはgc.cでなくても可能だが、そうすると関数を分ける必要がある。すると当然遅くなる。普通のプログラムではそんなことを気にしてはいけないけれども、ガーベージコレクタや評価器の核心部はruby最大のボトルネックなので、たとえ関数呼び出し一回と言えどもバカにならないのだ。

`ruby_frame`

ruby_frameはメソッド呼び出しを記録するスタックである。スタックフレーム構造体はstruct FRAMEだ。ちょっと用語が紛らわしいが、一般的な名詞の「スタックフレーム」のことを単にフレーム、struct FRAMEのことをFRAMEと書き分けるので注意してほしい。

▼ruby_frame

  16  extern struct FRAME {
  17      VALUE self;          /* self */
  18      int argc;            /* 引数の個数 */
  19      VALUE *argv;         /* 引数の値の配列 */
  20      ID last_func;        /* このFRAMEのメソッド名（呼んだ名前） */
  21      ID orig_func;        /* このFRAMEのメソッド名（定義時の名前） */
  22      VALUE last_class;    /* last_funcのレシーバのクラス */
  23      VALUE cbase;         /* 定数・クラス変数の検索の起点 */
  24      struct FRAME *prev;
  25      struct FRAME *tmp;   /* GC避け。後述 */
  26      struct RNode *node;  /* 実行中の行のファイル名と行番号 */
  27      int iter;            /* ブロック付き呼び出しか？ */
  28      int flags;           /* 以下の二つ */
  29  } *ruby_frame;

  33  #define FRAME_ALLOCA 0   /* FRAMEはスタック上に確保されている */
  34  #define FRAME_MALLOC 1   /* FRAMEはmallocで確保されている */

(env.h)

まず、prevメンバがあることからこのスタックはリンクリストで作られているとわかる（図2）。

(framestack)
図2: ruby_frame

ruby_xxxxが先端のスタックフレームを指すというのは以後全てのスタックに共通なのでいちいち書かない。

構造体の最初のメンバはselfだ。rb_eval()の引数にもselfがあったのにこちらでまた別にselfを記憶しているのはなぜだろう。それはCレベルの関数のためである。もっと言うとsuperに対応するrb_call_super()という関数のためである。superを実行するには現在のメソッドのレシーバが必要だが、rb_call_super()を呼ぶ側にはそんな情報があるはずがない。かと言ってユーザのCコードに制御が移っている時点でrb_eval()の連鎖はもう途切れている。だから情報ゼロの状態からselfの情報を得られるようにしておかなければならないという結論になる。そしてFRAMEはその置き場所としてちょうどいい。

もう少し考えてみると、argcやargvがあるのも不思議だ。パラメータ変数なんてのは結局ローカル変数なのだから、メソッド開始時に同名のローカル変数に代入してしまえばその後はもらった引数をとっておく必要などないのではないだろうか。ではこれは何に使うのかと言えば、実はこれまたsuperのためなのだ。Rubyでは引数なしでsuperを呼ぶとメソッドのパラメータ変数の値がスーパークラスのメソッドに引き渡されることになっている。そのためにはどうしてもパラメータ変数（に相当するローカル変数の領域）をとっておかなければならないのだ。

それとlast_funcとorig_funcの違いはaliasしたメソッドなどで出てくる。例えば

class C
  def orig() end
  alias ali orig
end
C.new.ali

という場合なら、last_func=aliでorig_func=origだ。このメンバにもやっぱりsuperがからんでいたりする。

`ruby_scope`

ruby_scopeはローカル変数スコープを表すスタックである。メソッド・クラス定義文・モジュール定義文・特異クラス定義文などが独立したスコープだ。スタックフレーム構造体はstruct SCOPEである。このフレームはSCOPEと呼ぼう。

▼ruby_scope

  36  extern struct SCOPE {
  37      struct RBasic super;
  38      ID *local_tbl;        /* ローカル変数名の配列 */
  39      VALUE *local_vars;    /* ローカル変数の格納領域 */
  40      int flags;            /* 以下の四つ */
  41  } *ruby_scope;

  43  #define SCOPE_ALLOCA  0         /* local_varsはalloca割り当て */
  44  #define SCOPE_MALLOC  1         /* local_varsはmalloc割り当て */
  45  #define SCOPE_NOSTACK 2         /* POP_SCOPEされている */
  46  #define SCOPE_DONT_RECYCLE 4    /* このSCOPEでProcが生成された */

(env.h)

最初の要素がstruct RBasicだからこれはRubyオブジェクトである。そうなっているのはProcオブジェクトに対処するためだ。例えば次のような場合を考えてみよう。

def make_counter
  lvar = 0
  return Proc.new { lvar += 1 }
end

cnt = make_counter()
p cnt.call    # 1
p cnt.call    # 2
p cnt.call    # 3
cnt = nil  # 参照を切る。作ったProcはここでやっと不要になる

このメソッドで作ったProcオブジェクトは作成元のメソッド自体よりも長生きする。そしてそのProcからもローカル変数lvarが参照できるので、作ったProcが消滅するまでローカル変数は保持しておかねばならない。だからガーベージコレクタで扱うようにしないと解放の時期がわからないのである。

またわざわざstruct SCOPEがstruct FRAMEから切り離されている理由は二点ある。一つめは、クラス定義文などはメソッド呼び出しではないがローカル変数スコープが独立していること。二つめは、Cで定義したメソッドを呼び出すときにはRubyのローカル変数領域が必要ないことだ。

`ruby_block`

struct BLOCKはRubyのイテレータブロックやProcオブジェクトの実体で、ある時点での評価器のスナップショットのようなものである。このフレームもFRAME・SCOPEと同じようにBLOCKと略記しよう。

▼ruby_block

 580  static struct BLOCK *ruby_block;

 559  struct BLOCK {
 560      NODE *var;               /* ブロックパラメータ（mlhs） */
 561      NODE *body;              /* ブロック本体のコード */
 562      VALUE self;              /* BLOCK生成時のself */
 563      struct FRAME frame;      /* BLOCK生成時のruby_frameのコピー */
 564      struct SCOPE *scope;     /* BLOCK生成時のruby_scope */
 565      struct BLOCKTAG *tag;    /* BLOCKのアイデンティティ */
 566      VALUE klass;             /* BLOCK生成時のruby_class */
 567      int iter;                /* BLOCK生成時のruby_iter */
 568      int vmode;               /* BLOCK生成時のscope_vmode */
 569      int flags;               /* BLOCK_D_SCOPE, BLOCK_DYNAMIC */
 570      struct RVarmap *dyna_vars;   /* ブロックローカル変数領域 */
 571      VALUE orig_thread;       /* ブロックを生成したスレッド */
 572      VALUE wrapper;           /* ブロック生成時のruby_wrapper */
 573      struct BLOCK *prev;
 574  };

 553  struct BLOCKTAG {
 554      struct RBasic super;
 555      long dst;                /* destinationつまり戻り先のこと */
 556      long flags;              /* BLOCK_DYNAMIC, BLOCK_ORPHAN */
 557  };

 576  #define BLOCK_D_SCOPE 1      /* 独立したブロック変数スコープを持つ */
 577  #define BLOCK_DYNAMIC 2      /* BLOCKがRubyプログラムから取り出された */
 578  #define BLOCK_ORPHAN  4      /* 生成元のFRAMEが終了している */

(eval.c)

frameがポインタではないことに注目。これはつまりstruct FRAMEの内容をまるごとコピーして保持するということである。struct FRAMEは（速度のために）マシンスタック上にベタ置きで確保されるのだが、BLOCKは生成元FRAMEよりも長生きする可能性があるので、その場合に備えてコピーしてある。

またstruct BLOCKTAGが分離されているのは、一つのブロックから複数の Procを生成した場合にも同じブロックであることを判定するためだ。同じブロックから生成したProcは同じBLOCKTAGを持つ。

`ruby_iter`

スタックruby_iterは現在呼び出し中のメソッドがイテレータであるか（ブロック付き呼び出しかどうか）を示す。フレームはstruct iterである。だが他のスタックフレームとの統一感を考えてITERと呼ぶことにしよう。

▼ruby_iter

 767  static struct iter *ruby_iter;

 763  struct iter {
 764      int iter;           /* 以下の三つ */
 765      struct iter *prev;
 766  };

 769  #define ITER_NOT 0      /* 現在評価中のメソッドはイテレータでない */
 770  #define ITER_PRE 1      /* これから呼ぶメソッドがイテレータである */
 771  #define ITER_CUR 2      /* 現在評価中のメソッドはイテレータである */

(eval.c)

イテレータであるかそうでないかはメソッド単位で決まるはずなのに、こうしてstruct FRAMEとは別の構造体が用意されているのはなぜだろうか。

メソッドに「イテレータである」場合にそれを知らせる必要があるのは当然として、「イテレータではない」場合にもその事実を知らせなければならない。しかしそのためにBLOCKをまるごと積むのはとても重い。呼び出し側の変数参照などの処理も無駄に増えてしまう。そこでBLOCKの代わりにもっと小さくて軽いITERを積もう、というわけだ。詳しいことは第16章『ブロック』で解説する。

`ruby_dyna_vars`

ブロックローカル変数領域。フレーム構造体は第二部でも見た struct RVarmapである。今後は単にVARSと呼ぶ。

▼struct RVarmap

  52  struct RVarmap {
  53      struct RBasic super;
  54      ID id;                  /* 変数名 */
  55      VALUE val;              /* その値 */
  56      struct RVarmap *next;
  57  };

(env.h)

注意してほしいのは、struct RVarmapはリストになって初めて一つのフレームなのだということだ（図3）。そして一つのフレームが一つのローカル変数スコープに対応している。「ローカル変数スコープ」であって「ブロックローカル変数スコープ」ではないので、ブロックがネストしているような場合はリスト一つで表現される。ブロックの区切りはパーサのときと似ていて、 id=0のRVarmap（ヘッダ）で表現される。詳しいことはこれまた先送りだ。第16章『ブロック』で解説する。

(vars)
図3: ruby_dyna_vars

`ruby_class`

ruby_classはdefでメソッドを定義するときに対象となるクラスを表す。普通のクラス定義文ではselfがそのクラスになるのでruby_class == selfだが、トップレベルやeval、instance_evalという特殊なメソッドの途中では self != ruby_classになることがある。

ruby_classのフレームは単純なVALUEで、フレーム構造体はない。ではどうやってスタックぽくするのだろうか。いやそれよりも、今までもprevポインタがない構造体がたくさんあったのだが、一体どうやってスタックにしているのだろう。答えは次の節で。

以後このフレームはCLASSと呼ぶことにする。

`ruby_cref`

ruby_crefはクラスのネスト関係を表している。フレームはこれまでと同じ命名法でCREFとする。その構造体は……

▼ruby_cref

 847  static NODE *ruby_cref = 0;

(eval.c)

……なぜかNODEだ。これは単に「新しく定義する必要のない、VALUEで指せる構造体」として使われているにすぎない。ノードタイプはNODE_CREFで、メンバ割り当ては以下のようになっている。

共用体メンバ	アクセスマクロ	使われかた
`u1.value`	`nd_clss`	外のクラス（`VALUE`）
`u2`	-	-
`u3.node`	`nd_next`	前の`CREF`を保持

メンバ名がnd_nextでも実際に保持するのは「前（prev）」のCREFである。例えば以下のプログラムを例にして実際の姿を説明しよう。

class A
  class B
    class C
      nil   # （A）
    end
  end
end

（A）のコードを評価しているとき、ruby_crefは図4のようになっている。

(crefstack)
図4: ruby_cref

だが毎回この図を書くのは繁雑なうえに意図が不明瞭になる。そこで以下では図4と同じ状態を次のように表記することにしよう。

A ← B ← C

`PUSH`/`POP`マクロ

以上のスタックフレーム構造体にはどれもプッシュ・ポップのためのマクロが用意されている。例えばFRAMEならPUSH_FRAME()とPOP_FRAME()、というように。すぐに実物が登場するので使いかたや内容はそのときに説明していくことにする。

その他の状態

これらのメインスタックほどは重要ではないものの、rubyの評価器には他にもいくつか状態がある。簡単に一覧しておこう。ただしこれらはスタックとは限らない。むしろそうでないことのほうが多い。

変数名	型	意味
`scope_vmode`	`int`	メソッド定義時のデフォルトの可視性
`ruby_in_eval`	`int`	評価開始後のパースであるか
`ruby_current_node`	`NODE*`	現在評価中のファイル名と行番号
`ruby_safe_level`	`int`	`$SAFE`
`ruby_errinfo`	`VALUE`	現在処理中の例外
`ruby_wrapper`	`VALUE`	環境を隔離するためのラッパーモジュール

モジュール定義

class文とmodule文、それに特異クラス定義文はどれも実装が似ている。似ているものを三つ続けて見ていっても面白くないので、今回は一番要素数が少ない（従って簡単な）module文を見ていくことにしよう。

ではまず、module文とはなんだろうか。逆に言うと、何が起こるべきなのが module文なのだろうか。いくつか特徴を挙げてみよう。

新しいモジュールオブジェクトが生成される
そのモジュールオブジェクトがselfになる
独立したローカル変数スコープを持つ
定数の代入を書くとそのモジュールに定数が定義される
クラス変数の代入を書くとそのモジュールにクラス変数が定義される
def文を書くとそのモジュールにメソッドが定義される。

こういうことをどうやって起こしているのか、それが今回のポイントだ。それではコードを見ていくことにしよう。

調査

▼ソースプログラム

module M
  a = 1
end

▼対応する構文木

NODE_MODULE
nd_cname = 9621 (M)
nd_body:
    NODE_SCOPE
    nd_rval = (null)
    nd_tbl = 3 [ _ ~ a ]
    nd_next:
        NODE_LASGN
        nd_cnt = 2
        nd_value:
            NODE_LIT
            nd_lit = 1:Fixnum

nd_cnameがモジュール名らしい。cnameはConst NAMEかClass NAMEか、どちらかだろう。またいくつかダンプしてみたがnd_bodyには必ず NODE_SCOPEが入っている。そのメンバnd_tblにローカル変数のテーブルが入っているし、struct SCOPEと名前が似ているところを考えても、この NODE_SCOPEがローカル変数スコープを作り出すために重要な役割を果たすのは間違いないようだ

`NODE_MODULE`

ではrb_eval()のNODE_MODULEのハンドラを見てみよう。rb_raise()関係、エラー処理、本筋と関係の薄いところはバッサリ削ってある。ここまで200ページ以上も削る作業をやってきたわけだから、もういちいち元のコードを示さなくてもいいだろう。

▼rb_eval()－NODE_MODULE（簡約版）

case NODE_MODULE:
  {
      VALUE module;

      if (rb_const_defined_at(ruby_class, node->nd_cname)) {
          /* 既に作成済のモジュールを得るだけ */
          module = rb_const_get(ruby_class, node->nd_cname);
      }
      else {
          /* 新しいモジュールを作成し定数にセットする */
          module = rb_define_module_id(node->nd_cname);
          rb_const_set(ruby_cbase, node->nd_cname, module);
          rb_set_class_path(module,ruby_class,rb_id2name(node->nd_cname));
      }

      result = module_setup(module, node->nd_body);
  }
  break;

まずモジュールがruby_class（に入っているモジュール）の上にネストして定義されているということを確認したい。それはruby_classに対して rb_const_xxxx()を呼んでいることからわかる。一回だけruby_cbaseというのも登場しているのだが、普通はruby_classと同じなので無視して構わない。この違いが問題になることもまずない。

前半、ifで分かれているのは、既に定義済のモジュールであるかどうかのチェックだ。Rubyでは一つのモジュールに対して何度でも「追加」定義ができるからである。

module M
  def a    # M#aを定義
  end
end
module M   # 定義の追加（再定義や上書きではない）
  def b    # M#bを定義
  end
end

このプログラムではモジュールMにaとb二つのメソッドが定義される。

このような場合、二回目のMの定義ではモジュールMは既に定数に入っているから、それを取り出して使うだけでいい。定数Mがない場合は初めての定義なので（rb_define_module_id()で）モジュールを作る。

最後にmodule_setup()だが、この関数がモジュール文本体の実行を行っている。モジュール文だけでなくクラス文や特異クラス文もmodule_setup()で実行する。「三つの文はどれも似たようなもの」と言ったのはそれが理由だ。とりあえず引数にnode->nd_body（NODE_SCOPE）を渡しているということに注目しておいてほしい。

`module_setup()`

モジュール文、クラス文、特異クラス文の本体の実行を行うのが module_setup()だ。いよいよRubyスタックの操作が大量に登場してくる。

▼module_setup()

3424  static VALUE
3425  module_setup(module, n)
3426      VALUE module;
3427      NODE *n;
3428  {
3429      NODE * volatile node = n;
3430      int state;
3431      struct FRAME frame;
3432      VALUE result;               /* OK */
3433      TMP_PROTECT;
3434
3435      frame = *ruby_frame;
3436      frame.tmp = ruby_frame;
3437      ruby_frame = &frame;
3438
3439      PUSH_CLASS();
3440      ruby_class = module;
3441      PUSH_SCOPE();
3442      PUSH_VARS();
3443
          /* （A）ruby_scope->local_varsの初期化 */
3444      if (node->nd_tbl) {
3445          VALUE *vars = TMP_ALLOC(node->nd_tbl[0]+1);
3446          *vars++ = (VALUE)node;
3447          ruby_scope->local_vars = vars;
3448          rb_mem_clear(ruby_scope->local_vars, node->nd_tbl[0]);
3449          ruby_scope->local_tbl = node->nd_tbl;
3450      }
3451      else {
3452          ruby_scope->local_vars = 0;
3453          ruby_scope->local_tbl  = 0;
3454      }
3455
3456      PUSH_CREF(module);
3457      ruby_frame->cbase = (VALUE)ruby_cref;
3458      PUSH_TAG(PROT_NONE);
3459      if ((state = EXEC_TAG()) == 0) {
3460          if (trace_func) {
3461              call_trace_func("class", ruby_current_node, ruby_class,
3462                              ruby_frame->last_func,
3463                              ruby_frame->last_class);
3464          }
3465          result = rb_eval(ruby_class, node->nd_next);
3466      }
3467      POP_TAG();
3468      POP_CREF();
3469      POP_VARS();
3470      POP_SCOPE();
3471      POP_CLASS();
3472
3473      ruby_frame = frame.tmp;
3474      if (trace_func) {
3475          call_trace_func("end", ruby_last_node, 0,
3476                          ruby_frame->last_func, ruby_frame->last_class);
3477      }
3478      if (state) JUMP_TAG(state);
3479
3480      return result;
3481  }

(eval.c)

一息で読むにはやや大きすぎる。いらなそうなところから削っていくことにしよう。

まずtrace_func周辺は無条件に消せる。

タグ関係のイディオムが見えるので、これももっとわかりやすく Rubyのensureで表現してしまおう。

関数開始直後、わざわざ引数のnをローカル変数nodeに代入しているが、 nodeにはvolatileが付いておりしかもそのあと全く代入していないことからこれはGC避けとわかる。よって最初から引数をnodeにしても意味は変わらない。

関数前半、ruby_frameをグチャグチャといじってるところと後半のruby_frame = frame.tmpはどう見ても対になっている。ここには後で注目するとして、とりあえずruby_frameのpush popと考えておく。

また（A）のコードはコメントの通りruby_scope->local_varsの初期化、とまとめられそうだ。後で詳述する。

結果的に以下だけにまとめられた。

▼module_setup（簡約版）

static VALUE
module_setup(module, node)
    VALUE module;
    NODE *node;
{
    struct FRAME frame;
    VALUE result;

    push FRAME
    PUSH_CLASS();
    ruby_class = module;
    PUSH_SCOPE();
    PUSH_VARS();
    ruby_scope->local_varsの初期化
    PUSH_CREF(module);
    ruby_frame->cbase = (VALUE)ruby_cref;
    begin
        result = rb_eval(ruby_class, node->nd_next);
    ensure
        POP_TAG();
        POP_CREF();
        POP_VARS();
        POP_SCOPE();
        POP_CLASS();
        pop FRAME
    end
    return result;
}

node->nd_nextをrb_eval()しているのでこれがモジュール文本体のコードであることはいいとしよう。問題はそれ以外だ。見るべきポイントは五つある。

PUSH_SCOPE() PUSH_VARS()で起こること
どうやってローカル変数領域を割り当てているか
PUSH_CLASS()の効果
ruby_crefとruby_frame->cbaseの関係
ruby_frameをいじって何をしているのか

順番に調査していこう。

ローカル変数スコープの生成

PUSH_SCOPE()がローカル変数領域を積み、PUSH_VARS()がブロックローカル変数領域を積むわけだから、この二つで新しいローカル変数スコープが作り出されることになる。これらのマクロの中身を追って、実際に何をしているのか見てみよう。

▼PUSH_SCOPE() POP_SCOPE()

 852  #define PUSH_SCOPE() do {               \
 853      volatile int _vmode = scope_vmode;  \
 854      struct SCOPE * volatile _old;       \
 855      NEWOBJ(_scope, struct SCOPE);       \
 856      OBJSETUP(_scope, 0, T_SCOPE);       \
 857      _scope->local_tbl = 0;              \
 858      _scope->local_vars = 0;             \
 859      _scope->flags = 0;                  \
 860      _old = ruby_scope;                  \
 861      ruby_scope = _scope;                \
 862      scope_vmode = SCOPE_PUBLIC

 869  #define POP_SCOPE()                                      \
 870      if (ruby_scope->flags & SCOPE_DONT_RECYCLE) {        \
 871         if (_old) scope_dup(_old);                        \
 872      }                                                    \
 873      if (!(ruby_scope->flags & SCOPE_MALLOC)) {           \
 874          ruby_scope->local_vars = 0;                      \
 875          ruby_scope->local_tbl  = 0;                      \
 876          if (!(ruby_scope->flags & SCOPE_DONT_RECYCLE) && \
 877              ruby_scope != top_scope) {                   \
 878              rb_gc_force_recycle((VALUE)ruby_scope);      \
 879          }                                                \
 880      }                                                    \
 881      ruby_scope->flags |= SCOPE_NOSTACK;                  \
 882      ruby_scope = _old;                                   \
 883      scope_vmode = _vmode;                                \
 884  } while (0)

(eval.c)

SCOPEもタグと一緒で、マシンスタックと同期させてスタックを作り出しているようだ。ただ微妙に違うのは、こちらはスタックフレームの領域自体はヒープから確保しており、スタック構造を作り出すためにマシンスタックを使っているというところだろう（図5）。

(scopestack)
図5: マシンスタックとSCOPEスタック

それとマクロの中で何度も出てくるSCOPE_なんたらというフラグについては、各スタックフレームの記憶形式とブロックのことを全て話してからでないと説明できない。第16章『ブロック』でまとめてやることにする。

ローカル変数領域の確保

何度も言っている通りローカル変数スコープはstruct SCOPEで表されるのだが、struct SCOPEは文字通り「スコープ」であって、ローカル変数を格納する実体がない。もうちょっと直截的に言うと、領域へのポインタはあってもその先の配列がないのだ。その配列を準備しているのが module_setup()の次の部分である。

▼ローカル変数スロットの準備

3444  if (node->nd_tbl) {
3445      VALUE *vars = TMP_ALLOC(node->nd_tbl[0]+1);
3446      *vars++ = (VALUE)node;
3447      ruby_scope->local_vars = vars;
3448      rb_mem_clear(ruby_scope->local_vars, node->nd_tbl[0]);
3449      ruby_scope->local_tbl = node->nd_tbl;
3450  }
3451  else {
3452      ruby_scope->local_vars = 0;
3453      ruby_scope->local_tbl  = 0;
3454  }

(eval.c)

冒頭のTMP_ALLOC()は次の項で見る。一言で言うと「確実にスタックに割り当ててくれる（従ってGCを考慮しなくてよい）alloca()」だ。

それでnode->nd_tblには実は第12章『構文木の構築』でやったローカル変数名のテーブルが入っている。つまりnd_tbl[0]にテーブルサイズが入っていて、残りはIDの配列になっている。そのテーブルはSCOPEのlocal_tblにそのまま移植し、またローカル変数の値を格納するためにlocal_varsを割り当てているようだ。このあたりは紛らわしいので「こっちが変数名」「こっちが値」と書き込んでおくといい。tblが付くほうが名前である。

さて、local_varsの割り当てを細かく見てみよう。local_tbl[0]がローカル変数の数だから、なぜかサイズを+1して割り当てている。ここには今度は module_setup()の引数node（NODE_SCOPE）を入れているようだ。つまりこの文が終わったところで図6のようになる。

(localvars)
図6: ruby_scope->local_vars

このnodeはどこで使われているのだろう。 local_varsメンバを洗ってみたがeval.cではインデックス-1へのアクセスは見当たらない。対象ファイルを広げてみると、gc.cでアクセスしていた。

▼rb_gc_mark_children()―T_SCOPE

 815  case T_SCOPE:
 816    if (obj->as.scope.local_vars &&
            (obj->as.scope.flags & SCOPE_MALLOC)) {
 817        int n = obj->as.scope.local_tbl[0]+1;
 818        VALUE *vars = &obj->as.scope.local_vars[-1];
 819
 820        while (n--) {
 821            rb_gc_mark(*vars);
 822            vars++;
 823        }
 824    }
 825    break;

(gc.c)

つまりどうやらこれはnodeをGCから保護するための仕掛けらしい。だがなぜマークしないといけないのだろう。nodeはわざわざvolatileなローカル変数に入れてあるのだから、module_setup()の実行中はGCされないはずである。

正直に言うと筆者はしばらくは単なる間違いだろうと思っていたのだが、実はとても意味があることがわかった。問題はその次の次の行のこれだ。

▼ruby_scope->local_tbl

3449  ruby_scope->local_tbl = node->nd_tbl;

(eval.c)

パーサで用意したローカル変数名のテーブルをそのまま使っている。このテーブルはいつ解放されるのだろう。それはこのnodeが参照されなくなったときである。ではnodeはいつ解放されるべきだろう。それはこの行で代入を行った SCOPEが全て消えてからである。ではそれはいつのことだろうか。

SCOPEはそれが生成される原因になった文よりも長生きすることがある。第16章『ブロック』で説明するとおり、Procオブジェクトを生成するとそこからSCOPEが参照されるからだ。つまりmodule_setup()が終わってもそこで作ったSCOPEが用済みになるとは限らない。だからnodeは module_setup()（のスタックフレーム）から参照されているだけでは不十分で、SCOPEから「直接に」参照されていなくてはならないのだ。

またその一方でローカル変数のvolatile nodeも外せない。でないと local_varsに代入するまでのあいだnodeが宙に浮いてしまう。

しかし、それなら今度はSCOPEのlocal_varsがまずいのではないだろうか。 TMP_ALLOC()は言ったとおりスタック割り当てなので、module_setup()の終了と同時に無効になってしまう。これが実は、Procを生成した時点でいきなりmalloc()割り当てに切り替えるようになっているのだ。詳しいことは第16章『ブロック』で解説する。

そして最後に、rb_mem_clear()は0充填かと思いきや実はVALUEの配列に対するQnil充填である（array.c）。これで全ての定義済みローカル変数が nilに初期化される。

`TMP_ALLOC()`

次にローカル変数の領域を実際に割り当てていたTMP_ALLOC()を読もう。このマクロは実はmodule_setup()の最初のほうにひっそりと存在する TMP_PROTECTと組になっている。典型的な使いかたはこうだ。

VALUE *ptr;
TMP_PROTECT;

ptr = TMP_ALLOC(size);

なぜTMP_PROTECTがローカル変数定義の位置にあるかというと…… 定義を見てみよう。

▼TMP_ALLOC()

1769  #ifdef C_ALLOCA
1770  # define TMP_PROTECT NODE * volatile tmp__protect_tmp=0
1771  # define TMP_ALLOC(n) \
1772      (tmp__protect_tmp = rb_node_newnode(NODE_ALLOCA,                 \
1773                               ALLOC_N(VALUE,n), tmp__protect_tmp, n), \
1774       (void*)tmp__protect_tmp->nd_head)
1775  #else
1776  # define TMP_PROTECT typedef int foobazzz
1777  # define TMP_ALLOC(n) ALLOCA_N(VALUE,n)
1778  #endif

(eval.c)

……ローカル変数を定義しているから。というのが答えだ。

第5章『ガ－ベージコレクション』で解説したとおり、#ifdef C_ALLOCAの（ネイティブの alloca()がない）環境ではmalloc()でalloca()をエミュレートしている。しかしメソッドの引数というのは当然VALUEであり、ヒープにVALUEを置いてしまうとGCで検出できなくなってしまう。そこでNODEを経由して無理矢理 GCの対象にする（図7）。

(tmpprotecttmp)
図7: NODE経由で領域をスタックに繁ぎ止める

一方、真のalloca()がある環境では普通にalloca()を使えばいいので TMP_PROTECTは必要ない。そこで無害な式を適当に入れておく。

ところで、なぜここまでしてalloca()を使いたがるのだろうか。その理由は単に「alloca()のほうがmalloc()より速いから」だそうだ。そのくらいの違いはどうでもいいような気もするのだが、なにしろ評価器コアはruby最大のボトルネックなので、以下同文。

メソッド定義先の変更

スタックruby_classの値がそのときのメソッドの定義先クラスになる。逆に言うとruby_classに値をプッシュすると定義先クラスが変わる。それこそがクラス文に必要なことだ。従ってmodule_setup()でもPUSH_CLASS()しなければならない。それがこのコードだ。

PUSH_CLASS();
ruby_class = module;
     ：
     ：
POP_CLASS();

なぜPUSH_CLASS()してからruby_classに改めて代入しているのだろう。これは定義を見ると意外とあっさりわかる。

▼PUSH_CLASS() POP_CLASS()

 841  #define PUSH_CLASS() do { \
 842      VALUE _class = ruby_class

 844  #define POP_CLASS() ruby_class = _class; \
 845  } while (0)

(eval.c)

PUSH_CLASS()してもruby_classが書き換わるわけではないので、そのあとに手でセットしないと本当にプッシュしたことにならないのだ。だからこの二つは「プッシュ・ポップ」というよりは「保存・復帰」に近い。

PUSH_CLASS()の引数にクラスを渡すようにすればもっときれいなマクロになるじゃないか……というのは全くその通りなのだが、プッシュする前にクラスが得られない場所があるためにこういうことになっている。

クラスのネスト

ruby_crefは実行中のクラスネスト情報を表現しているのだった。だからモジュール文やクラス文でruby_crefが積まれるのは当然予想できる。 module_setup()ではこんなふうに積んでいた。

PUSH_CREF(module);
ruby_frame->cbase = (VALUE)ruby_cref;
   ：
   ：
POP_CREF();

ここで、moduleは定義中のモジュールである。 PUSH_CREF()とPOP_CREF()の定義も見ておこう。

▼PUSH_CREF() POP_CREF()

 849  #define PUSH_CREF(c) \
          ruby_cref = rb_node_newnode(NODE_CREF,(c),0,ruby_cref)
 850  #define POP_CREF() ruby_cref = ruby_cref->nd_next

(eval.c)

PUSH_SCOPE()などのようなとんでもない工夫があるわけでもなく、非常に扱いやすい。やはりたまにはこういうのもないと困る。

すると残る問題はruby_frame->cbaseが何を意味しているのかということだが、これは現在のFRAME内から定数やクラス変数を参照するのに使う情報である。詳しいことは本章の最後の節で見ていく。

フレームのすりかえ

最後にruby_frameの操作に注目する。まずは定義のところから。

struct FRAME frame;

ポインタではない。つまりこれはマシンスタック上にFRAMEをベタ置きで確保するという意味である。Rubyスタックの管理構造もローカル変数領域もマシンスタック上だったが、なんとFRAMEに至っては構造体まるごとスタック上に置いてしまおうというのだ。rubyがマシンスタックをバカ食いするのもこういう「小さな工夫」が積み重なった成果なのである。

そして次にframeを何やらいろいろしているところを見よう。

frame = *ruby_frame;      /* 構造体まるごとコピー */
frame.tmp = ruby_frame;   /* 元のFRAMEをGCから保護する */
ruby_frame = &frame;      /* ruby_frameを差し替える */
       ：
       ：
ruby_frame = frame.tmp;   /* 戻す */

つまりruby_frameを一時的に差し替えている（プッシュではない）ようだ。どうしてこんなことをしているのだろう。

FRAMEというのは「メソッド呼び出しで積まれる」と説明したが、より厳密に言うと「Rubyプログラムを実行するうえでの主な環境」を表すスタックフレームなのだ。例えば先程出てきたruby_frame->cbaseなどを見るとそういう意味合いが見て取れる。他にも「最後に呼んだメソッド名」を表すlast_funcなどもそうだ。

ではどうしてここで素直にFRAMEを積まないかというと、ここはFRAMEを積んでいい場所ではないからである。仕組みから言えば本当はFRAMEを積みたいわけだが、FRAMEを積むと例外が発生したときにプログラムのバックトレースにそれが出てしまう。バックトレースというのは次のような表示のことだ。

% ruby t.rb
t.rb:11:in `c': some error occured (ArgumentError)
        from t.rb:7:in `b'
        from t.rb:3:in `a'
        from t.rb:14

しかしモジュール文やクラス文はメソッド呼び出しではないからこの中には出てきてほしくない。だから「積まずに」、「差し替える」わけだ。

メソッドの定義

モジュール定義の次はメソッドの定義を見ていくことにしよう。

調査

▼ソースプログラム

def m(a, b, c)
  nil
end

▼対応する構文木

NODE_DEFN
nd_mid  = 9617 (m)
nd_noex = 2 (NOEX_PRIVATE)
nd_defn:
    NODE_SCOPE
    nd_rval = (null)
    nd_tbl = 5 [ _ ~ a b c ]
    nd_next:
        NODE_ARGS
        nd_cnt  = 3
        nd_rest = -1
        nd_opt = (null)
        NODE_NIL

いくつかダンプしてみたところ、nd_defnには常にNODE_SCOPEが入っているようだ。NODE_SCOPEと言えばモジュール文のところでも見たようにローカル変数スコープを積むための情報を格納するノードである。

`NODE_DEFN`

続いてrb_eval()の該当コードを見ていく。エラー処理がやたら多くて面倒だったので再び全部まとめて省略した。その方法はいつもと同じである。即ちrb_raise() rb_warn() rb_warning()を呼ぶだけのもの、および間接的にそれを呼ぶものを全部消した。

▼rb_eval()－NODE_DEFN（簡約版）

NODE *defn;
int noex;

if (SCOPE_TEST(SCOPE_PRIVATE) || node->nd_mid == init) {
    noex = NOEX_PRIVATE;                 （A）
}
else if (SCOPE_TEST(SCOPE_PROTECTED)) {
    noex = NOEX_PROTECTED;               （B）
}
else if (ruby_class == rb_cObject) {
    noex =  node->nd_noex;               （C）
}
else {
    noex = NOEX_PUBLIC;                  （D）
}

defn = copy_node_scope(node->nd_defn, ruby_cref);
rb_add_method(ruby_class, node->nd_mid, defn, noex);
result = Qnil;

前半にはprivateだのprotectedだのという単語が出てくるので可視性関係だろう。フラグの名前に使われているnoexはNOde EXposure（ノードの可視性）だと思われる。if文の節を順番に見ていこう。

（A）SCOPE_TEST()はscope_vmodeに引数のフラグが立っているか確認するマクロである。従ってこの条件文の前半は「privateスコープであるか」という意味だ。後半は「initializeの定義ならprivate」である。オブジェクトの初期化用メソッドinitializeは問答無用でprivateになるのだ。

（B）protectedスコープだったらprotected（あたりまえ）。 Rubyではprotectedはいまいち使い手がないような気がする。

（C）ここはバグっている。本書の入稿直前に発見したので修正は間に合わなかった。最新のコードではなくなっているはずだ。トップレベルで定義されたメソッドを確実にprivateにしようとした、というのが元々の意図である。

（D）これまでのどれでもなかったら、publicだ。

さて、実はここまではどうでもいい。重要なのはその次の二行である。

defn = copy_node_scope(node->nd_defn, ruby_cref);
rb_add_method(ruby_class, node->nd_mid, defn, noex);

copy_node_scope()はメソッド本体の先頭に付いている NODE_SCOPE（だけ）をコピーする関数だ。ruby_crefを渡しているところがポイントなのだが……詳しくはすぐ後で見ていく。

コピーしたあと、それをrb_add_method()で追加すれば定義は完了である。定義する先はもちろんruby_classだ。

`copy_node_scope()`

copy_node_scope()はrb_eval()のメソッド定義（NODE_DEFN）と特異メソッド定義（NODE_DEFS）だけから呼ばれるので、その二ヶ所だけ見れば使われかたを特定できる。そしてその二ヶ所での使いかたはほぼ同じだ。

▼copy_node_scope()

1752  static NODE*
1753  copy_node_scope(node, rval)
1754      NODE *node;
1755      VALUE rval;
1756  {
1757      NODE *copy = rb_node_newnode(NODE_SCOPE,0,rval,node->nd_next);
1758
1759      if (node->nd_tbl) {
1760          copy->nd_tbl = ALLOC_N(ID, node->nd_tbl[0]+1);
1761          MEMCPY(copy->nd_tbl, node->nd_tbl, ID, node->nd_tbl[0]+1);
1762      }
1763      else {
1764          copy->nd_tbl = 0;
1765      }
1766      return copy;
1767  }

(eval.c)

引数のrvalはメソッドが定義された時のクラスのネスト情報（ruby_cref）だった。nd_rvalにセットされるからrvalということだろう。

本体のif文ではNODE_SCOPEのnd_tblをコピーしている。つまりローカル変数名のテーブルである。ALLOC_N()で+1しているのはnd_tbl[0]の分も合わせて確保するためだ。第二部で見たとおりnd_tbl[0]にはローカル変数の数が入っており、それはつまり「nd_tblの実際の長さ-1」だった。

まとめると、copy_node_scope()はメソッド本体のヘッダであるNODE_SCOPEを複製する、ただしnd_rvalが追加でセットされる。そしてそれはクラスを定義したときのruby_cref（クラスのネスト情報）である。この情報は後で定数やクラス変数の参照のときに使われる。

`rb_add_method()`

次にメソッドエントリを登録する関数rb_add_method()だ。

▼rb_add_method()

 237  void
 238  rb_add_method(klass, mid, node, noex)
 239      VALUE klass;
 240      ID mid;
 241      NODE *node;
 242      int noex;
 243  {
 244      NODE *body;
 245
 246      if (NIL_P(klass)) klass = rb_cObject;
 247      if (ruby_safe_level >= 4 &&
              (klass == rb_cObject || !OBJ_TAINTED(klass))) {
 248          rb_raise(rb_eSecurityError, "Insecure: can't define method");
 249      }
 250      if (OBJ_FROZEN(klass)) rb_error_frozen("class/module");
 251      rb_clear_cache_by_id(mid);
 252      body = NEW_METHOD(node, noex);
 253      st_insert(RCLASS(klass)->m_tbl, mid, body);
 254  }

(eval.c)

NEW_METHOD()はNODEを生成するマクロだ。 rb_clear_cache_by_id()はメソッドキャッシュを操作する関数である。次章『メソッド』で説明する。

では、最終的にクラスのm_tblに格納される構文木を見てみよう。こういうときのために用意しておいた nodedump-method\footnote{nodedump-method：nodedumpに同梱。nodedumpは添付CD-ROMのtools/nodedump.tar.gz}を使う。

% ruby -e '
class C
  def m(a)
    puts "ok"
  end
end
require "nodedump-method"
NodeDump.dump C, :m        # クラスCのメソッドmをダンプする
'
NODE_METHOD
nd_noex = 0 (NOEX_PUBLIC)
nd_cnt = 0
nd_body:
    NODE_SCOPE
    nd_rval = Object <- C
    nd_tbl = 3 [ _ ~ a ]
    nd_next:
        NODE_ARGS
        nd_cnt  = 1
        nd_rest = -1
        nd_opt = (null)
        U牙�S頏著


** unhandled**

恐らくメソッドのヘッダを意味するのだろう、NODE_METHODが先頭に付いており、その次に先程copy_node_scope()でコピーしたNODE_SCOPEが付く。いくつかダンプしてみたところCで定義したメソッドにはNODE_SCOPEは付いていなかったので、これがRubyレベルで定義したメソッドの印らしい。

またNODE_SCOPEのnd_tblにメソッドのパラメータ変数名（a）が登場している。以前、パラメータ変数は普通のローカル変数と同じだと言ったが、それがここに端的に出ているわけだ。

NODE_ARGSについては次の次章『メソッド』で扱うので省略。

それと最後にNODE_METHODのnd_cntだが、これは今回はあまり気にしなくていい。aliasがからんだときに使うものだ。

代入と参照

考えてみればスタックのほとんどは各種変数を実現するために存在するわけだ。ここまででいろいろスタックを積めるようになったので、今度は変数参照のコードを見ていこう。

ローカル変数

ローカル変数の代入・参照に必要な情報はここまでで全て登場しているので予測が付くだろう。ポイントは以下の二点だ。

ローカル変数領域はruby_scope->local_varsが指す配列である。
ローカル変数名と配列インデックスの対応はパーサレベルで解決済み。

ということでローカル変数参照のノードNODE_LVARのコードはこうなる。

▼rb_eval()－NODE_LVAR

2975  case NODE_LVAR:
2976    if (ruby_scope->local_vars == 0) {
2977        rb_bug("unexpected local variable");
2978    }
2979    result = ruby_scope->local_vars[node->nd_cnt];
2980    break;

(eval.c)

言うまでもないと思うがnode->nd_cntがパーサのlocal_cnt()で返していた値である。

定数

完全仕様

第6章『変数と定数』で定数の格納形式とAPIについては話した。定数はクラスに所属し、メソッドと同じように継承する。また現実の姿としては struct RClassのiv_tblにインスタンス変数やクラス変数と一緒に登録されているのであった。

しかし定数の検索パスはまず外のクラス、次にスーパークラスを探すはずなのに、rb_const_get()ではスーパークラスしか検索していなかった。それはどうしてだろうか。それについて話すには定数に隠された最後の仕様について話さなくてはならない。次のコードを見てほしい。

class A
  C = 5
  def A.new
    puts C
    super
  end
end

A.newはAの特異メソッドなので所属クラスは特異クラス(A)である。だから規則通りに解釈するならばAに所属する定数Cを取れるわけがない。

しかしこう近くに書いてあれば定数Cを参照したくなるのが人情というものだ。それゆえRubyではこういう参照もできてしまう。このような仕様は「ソースコードの見ためを重視する」というRubyの性格を反映していると言えるだろう。

この規則を一般化するとこうなる。即ちメソッドの内部から定数を参照した場合、メソッド定義を「書いた」場所のクラスを起点にして外のクラスの定数を参照する。そして「メソッドを書いた場所のクラス」はコンテキスト依存でありパーサと評価器両方の情報がなければ扱えない。それがrb_const_get()に外のクラスの検索パスがなかった理由である。

`cbase`

そこで外のクラスまで含めた定数参照のコードを見てみよう。 ::が付かない普通の定数参照は構文木ではNODE_CONSTになる。 rb_eval()でのそのコードはと言うと……

▼rb_eval()－NODE_CONST

2994  case NODE_CONST:
2995    result = ev_const_get(RNODE(ruby_frame->cbase), node->nd_vid, self);
2996    break;

(eval.c)

まずnd_vidがVariable IDで定数名だろう。そしてruby_frame->cbaseが「メソッド定義を書いた場所のクラス」である。この値はメソッドを起動したときにセットされるものなのでまだそのコードは登場していないが、そのセットする値がさらにどこから来ているかと言うと、これがメソッド定義の copy_node_scope()で出てきたnd_rvalなのである。少し戻ってきて見てほしいのだが、このメンバにはメソッド定義時のruby_crefが入っているはずだ。

つまり、まずクラスやモジュール定義のときにruby_crefのリンクが形成される。いま定義したクラスをCとしよう（図81）。

ここでメソッドmを定義すると（たぶんC#m）、そのときのruby_crefがメソッドエントリに記憶される（図82）。

その後クラス文が終わればruby_crefは別のノードを指していくわけだが、 node->nd_rvalは当然同じものを指し続ける（図83）。

そしてメソッドC#mを起動するときにはnode->nd_rvalを取り出して、積んだばかりのruby_frame->cbaseに入れる（図84）。

……という仕組みなのである。ややこしい。

(cbase)
図8: CREFの伝達

`ev_const_get()`

ではNODE_CONSTのコードに戻るとしよう。残りはev_const_get()だけだから、それを見る。

▼ev_const_get()

1550  static VALUE
1551  ev_const_get(cref, id, self)
1552      NODE *cref;
1553      ID id;
1554      VALUE self;
1555  {
1556      NODE *cbase = cref;
1557      VALUE result;
1558
1559      while (cbase && cbase->nd_next) {
1560          VALUE klass = cbase->nd_clss;
1561
1562          if (NIL_P(klass)) return rb_const_get(CLASS_OF(self), id);
1563          if (RCLASS(klass)->iv_tbl &&
                  st_lookup(RCLASS(klass)->iv_tbl, id, &result)) {
1564              return result;
1565          }
1566          cbase = cbase->nd_next;
1567      }
1568      return rb_const_get(cref->nd_clss, id);
1569  }

(eval.c)

引数のcref、つまり元はruby_cref、はNODEを利用したリンクリストであった。そのリストを辿りながら直接st_lookup()でiv_tblを調べる。外のクラスのスーパークラスまでは調べないのが仕様だから、rb_const_get()ではいけない。

そしてklassがnilになったら……つまりトップレベルを越えたら、もうネストしているクラスはないのでスーパークラス方向を調べる。こちらは rb_const_get()一発でよい。

さらに、スーパークラス方向を調べるときは一転してselfが起点になる。本当にややこしい。

クラス変数

クラス変数の参照先もruby_crefである。ただしもちろん、定数のように外のクラスを次々と探したりはしないので使うのは最初の一つだけだ。クラス変数参照のノード、NODE_CVARのコードを見てみよう。

▼rb_eval()－NODE_CVAR

2998        case NODE_CVAR:
2999          result = rb_cvar_get(cvar_cbase(), node->nd_vid);
3000          break;

(eval.c)

cvar_cbase()というのはなんだろうか。cbaseと付くところを見ると ruby_frame->cbaseと関係がありそうだが、どう違うのだろうか。見てみよう。

▼cvar_cbase()

1571  static VALUE
1572  cvar_cbase()
1573  {
1574      NODE *cref = RNODE(ruby_frame->cbase);
1575
1576      while (cref && cref->nd_next &&
                 FL_TEST(cref->nd_clss, FL_SINGLETON)) {
1577          cref = cref->nd_next;
1578          if (!cref->nd_next) {
1579    rb_warn("class variable access from toplevel singleton method");
1580          }
1581      }
1582      return cref->nd_clss;
1583  }

(eval.c)

特異クラスでないところまでcbaseを遡る、らしい。これは次のようなコード対策のために付け加えられたものだ。

class C                           class C
  @@cvar = 1                        @@cvar = 1
  class << C                        def C.m
    def m                             @@cvar
      @@cvar                        end
    end                             def C.m2
    def m2                            @@cvar + @@cvar
      @@cvar + @@cvar               end
    end                           end
  end
end

このプログラムは左右どちらのように書いても定義されるメソッドは同じだ。だが右の書きかたはメソッドが増えてくると何度もクラス名を書かなくてはいけないので面倒くさい。だから特異メソッドを複数定義するときは左のように特異クラス定義文でまとめてしまう人も多いのだ。

ところがこの二つの書き方ではruby_crefの値が違う。特異クラス定義を使うほうはruby_cref=(C)であり、バラバラに特異メソッドを定義するほうでは ruby_cref=Cである。これではクラス変数の参照先が変わってしまい不便だ。

そこで、特異クラスにクラス変数を定義することはあまりないだろうと判断して特異クラスは飛び越えるようになっているのである。ここでもまた一貫性より使いやすさ重視の仕様になっているわけだ。

ちなみに定数参照の場合は外のクラスを全て探すからどちらの書きかたでも Cが検索パスに入るので問題ない。また代入のほうはそもそもメソッド中に書けないのでこれも関係ない。

多重代入

Rubyで一番複雑な仕様はどこだ、と問われれば筆者は即座に多重代入と答える。多重代入の全体像を把握するなんて無理だ。そう思う根拠もある。ようするに、多重代入の仕様は仕様全体をきれいに設計しようなんてこれっぱかしも思わずに作られているのだ。仕様の基準になるのは常に「いくつかの典型的な使用パターンで便利だと思われる挙動」である。このことはRuby全体に言えるが、多重代入は特にそれが顕著だ。

ではどうすればコードの密林で迷わずに済むだろうか。これは状態付きスキャナを読むのと似ていて、全体を見ないことである。そもそも全体像がないのだから、全体像を把握することもできないのだ。コードをブツ切りにして、このコードはこの仕様のためにある、ここのコードはこの仕様のためにある……というふうに逐一対応を取っていくしかない。

ただ本書はrubyの構造を包括的に理解する本であって『Rubyプログラミング上級編』ではないので、あまりに細かいことをやっても仕方がない。そこでここでは多重代入の基本的な仕組みと、ごく簡単な「多対多」の場合だけを考えることにする。

ではまず定番通り構文木から見ていくことにする。

▼ソースプログラム

a, b = 7, 8

▼対応する構文木

NODE_MASGN
nd_head:
    NODE_ARRAY [
    0:
        NODE_LASGN
        nd_cnt = 2
        nd_value:
    1:
        NODE_LASGN
        nd_cnt = 3
        nd_value:
    ]
nd_value:
    NODE_REXPAND
    nd_head:
        NODE_ARRAY [
        0:
            NODE_LIT
            nd_lit = 7:Fixnum
        1:
            NODE_LIT
            nd_lit = 8:Fixnum
        ]

右辺・左辺がともにNODE_ARRAYのリストになり、右辺にはNODE_REXPANDも付く。REXPANDはRight value EXPANDだろうか。このノードが何をやっているのか気になる。見てみよう。

▼rb_eval()－NODE_REXPAND

2575  case NODE_REXPAND:
2576    result = avalue_to_svalue(rb_eval(self, node->nd_head));
2577    break;

(eval.c)

avalue_to_svalue()は無視していい。 rb_eval()でNODE_ARRAYが評価され、（それは配列リテラルのノードなので、） Rubyの配列になって返ってくる。つまり左辺を扱う前に右辺は全て評価されてしまうわけだ。だからこそ次のようなこともできる。

a, b = b, a    # 一行で書く変数スワップ

では左辺側のNODE_MASGNも見てみよう。

▼rb_eval()－NODE_MASGN

2923  case NODE_MASGN:
2924    result = massign(self, node, rb_eval(self, node->nd_value),0);
2925    break;

(eval.c)

ここでは右辺の評価だけで残りはmassign()に委譲だ。

`massign()`

▼massi……

3917  static VALUE
3918  massign(self, node, val, pcall)
3919      VALUE self;
3920      NODE *node;
3921      VALUE val;
3922      int pcall;
3923  {

(eval.c)

リストの途中で申し訳ないが、ここで止まって第四引数に注目してほしい。 pcallはProc CALL、つまりこの関数がProcオブジェクトの呼び出しのために使われているのかどうかを示している。Proc呼び出しとその他では多重代入のチェックの厳しさが少し違うので、ここでフラグをもらってチェックしているわけだ。当然、値は0か1のどちらかと決まっている。

そこで先程のmassign()の呼び出しコードを見てほしいのだが、pcall=0だ。それならとりあえずpcall=0と決め打ちにして変数を展開してしまっても構わないのではないだろうか。というのも、pcallのように動作を微妙に変える引数があると常に二通りの筋書きを考えながら読まないとならず、非常に面倒くさいからだ。たとえ実際の関数massign()は一つだとしても、読むときには pcall=0とpcall=1の場合の二つの関数があると考えたほうがずっと読みやすい。

プログラムを書くときには二重化は是非とも避けなければならないが、読むときに限ってはその原則は無関係である。パターンが限られているならむしろコピーして冗長化するほうが正しい。「速度に関して最適化」「コードサイズに関して最適化」という言葉があるが、この場合は「読みやすさに関して最適化」するのである。

そこでpcall=0として削れるところを全部削った姿を以下に示す。

▼massign()（簡約版）

static VALUE
massign(self, node, val  /* , pcall=0 */)
    VALUE self;
    NODE *node;
    VALUE val;
{
    NODE *list;
    long i = 0, len;

    val = svalue_to_mvalue(val);
    len = RARRAY(val)->len;
    list = node->nd_head;
    /* （A） */
    for (i=0; list && i<len; i++) {
        assign(self, list->nd_head, RARRAY(val)->ptr[i], pcall);
        list = list->nd_next;
    }
    /* （B） */
    if (node->nd_args) {
        if (node->nd_args == (NODE*)-1) {
            /* no check for mere `*' */
        }
        else if (!list && i<len) {
            assign(self, node->nd_args,
                   rb_ary_new4(len-i, RARRAY(val)->ptr+i), pcall);
        }
        else {
            assign(self, node->nd_args, rb_ary_new2(0), pcall);
        }
    }

    /* （C） */
    while (list) {
        i++;
        assign(self, list->nd_head, Qnil, pcall);
        list = list->nd_next;
    }
    return val;
}

valが右辺の値だ。またsvalue_to_mvalue()という怪しい変換をかけているが、先程がmvalue_to_svalue()、今回がsvalue_to_mvalue()だから「きっと元に戻っているはずだ」と考えられる。従って両方まとめて消す。また次の行で RARRAY()を使っているから、右辺の値はRubyのArrayになっているらしいとわかる。一方左辺はnode->nd_head、つまりローカル変数listに代入されている値である。このlistもまたノード（NODE_ARRAY）だ。

以下はコードを節ごとに追っていく。

（A）assign()はその名前通り、一対一の代入を行う関数である。左辺はノードで表現されているから、例えばNODE_IASGN（インスタンス変数への代入）ならrb_ivar_set()で代入する、というようにすればいい。つまりここでは listとvalの短いほうに合わせて一対一の代入を行っている（図9）。

(massign)
図9: 対応するものは代入

（B）右辺が余っていたら残りをRubyの配列にしてnode->nd_args（が表現している左辺）に代入する。

（C）左辺が余っていたらその全部にnilを代入する。

ところで、pcall=0にして削る、という作業はコンパイラの最適化フェイズで使うデータフロー解析／定数畳み込みとそっくりだ。つまりある程度自動化できるのではないかと考えられる。

御意見・御感想・誤殖の指摘などは青木峰郎 <aamine@loveruby.net> までお願いします。

『Rubyソースコード完全解説』はインプレスダイレクトで御予約・御購入いただけます (書籍紹介ページへ飛びます)。

第14章 コンテキスト

Rubyスタック

コンテキストとスタック

ruby_frame

ruby_scope

ruby_block

ruby_iter

ruby_dyna_vars

ruby_class

ruby_cref

PUSH/POPマクロ

その他の状態

モジュール定義

調査

NODE_MODULE

module_setup()

ローカル変数スコープの生成

ローカル変数領域の確保

TMP_ALLOC()

メソッド定義先の変更

クラスのネスト

フレームのすりかえ

メソッドの定義

調査

NODE_DEFN

copy_node_scope()

rb_add_method()

代入と参照

ローカル変数

定数

完全仕様

cbase

ev_const_get()

クラス変数

多重代入

massign()

第14章コンテキスト

`ruby_frame`

`ruby_scope`

`ruby_block`

`ruby_iter`

`ruby_dyna_vars`

`ruby_class`

`ruby_cref`

`PUSH`/`POP`マクロ

`NODE_MODULE`

`module_setup()`

`TMP_ALLOC()`

`NODE_DEFN`

`copy_node_scope()`

`rb_add_method()`

`cbase`

`ev_const_get()`

`massign()`