##GREF-CHECK #<identifier user#foo>
GREF-PUSH #<identifier user#a>
GREF-PUSH #<identifier user#b>
GREF-TAIL-CALL(2) #<identifier user#foo>
#みたいに、先に関数のbindingのチェックをしてくれるといいと思うことがあるんですが、パフォーマンス的に厳しいですか?
#私は、よく (use util.match) を忘れて、似たような目に合うことが多いです。
#Scheme的には(f <expr>)でfが未定義でもエラーにはできないんです。<expr>が他の継続を呼び出す可能性があるので。
#あーでも<expr>が変数参照の場合は他の継続を呼び出す可能性が無いから、特別扱いすることはありかも。エラーが起きた後なら少々コストがかかっても良いので、GREFでエラーが起きた時に自分を引数としている関数呼び出しの方をチェックにいけるような何かがあればいいかな。
#エラーが起きた箇所からインストラクション列を調べて怪しいGREFを見つけられるか。インストラクションを見ていって、PRE-CALL/CALLのペアを除いてはじめて出会うGREF-CALLがあったらそいつの束縛を調べればいいのかな。
#そうか、継続呼び出しのケースがあったのか。MzSchemeだと
#> (define (foo) (bar (a b)))
> (foo)
reference to undefined identifier: bar
#となるけど、どうやっているんだろう?
#(define (foo) (call/cc (lambda (k) (bar (k 'ok))))) が通るのなら、コンパイル時ではなくエラー発生時に賢いことをしてるのでしょうね。
#それだと、エラーなく通りましたね。
Gauche > Archives > 2013/12/23