Enbug

かなり大きめなバグを0.4.0で埋め込んだみたいである。問題になるのは以下のコード。

(define (foo)
  (define (bar n) (print n))
  (bar 1)
  (let ()
    (define (bar n) (print 'hoge))
    (bar 1)))

何の変哲もないコードだが、0.4.0では「CレベルのASSERTで落ちる」という脅威の振る舞いをしてくれる。

マクロ直しの一環でのEnbugなのだが、正直全く気づかなかった。久しぶりにベンチマークでも取るかとGambitベンチマークを走らせてはじめて発覚。この問題の面白い(いやな)ところは、実行されたインストラクションから見ると問題の箇所はラムダリフティングに見えた点。実はそこではなく、barが2箇所で使われている点にある。

なぜこんなバグを混入することになったかといえば、R6RS及びR7RSではdefine-syntaxが内部defineと同様に書けることに起因する。たとえば以下のコード。

(let ()
  (define even?
    (lambda (x)
      (or (= x 0) (odd? (- x 1)))))
  (define-syntax odd?
    (syntax-rules ()
      ((odd?  x) (not (even? x)))))
  (even? 10))

こんなコードがあった際に、コンパイラはまずマクロのコンパイルをする。その後、内部defineのコンパイルをする。っが、実は一箇所大きめの落とし穴があって、どちらのコンパイルの際でも内部defineの名前を局所変数として登録する。つまり2重登録が発生する。っで、これの解決の方法がまずかった。

2重で登録されているのなら、2つ目に来るものは無視すればいいのだろうと安易に考えたのだが、そのをしたら最初のコードが動かなくなった。ある意味当たり前である。同名がくることは一切考えていなかったのだから。

リリース直後に気づいた不具合の致命的度としては最大級な気がする・・・orz

備忘録も兼ねてどう解決したか。

最初のコードが問題になったのはどのフレームに属する局所変数かを見分ける術がなかったので普通のルックアップではたどってはいけないフレームまでたどって参照していたのが問題になっていた。
そこで、局所マクロと内部define(初回)の局所変数定義を同じフレームに突っ込んで、実際に内部defineがコンパイルされる2回目は直前のフレームのみを参照して同じ名前があればその情報をなければ作るという形にした。
もともと局所マクロのフレームが異なっていたのは単に手抜きというかそこまで考えていなかっただけなので、特に問題はないはず。