[ruby-dev:35007] Re: [ruby-changes:5517] Ruby:r17021 (trunk): * vm_insnhelper.c, vm.c, proc.c (proc_call): allow call method with

遠藤です。

2008/06/09 4:08 Yukihiro Matsumoto <[e-mail]>:
> |　2 については，今は rb_iterate に渡す関数ポインタの引数が ANYARGS
> |なので無理です．
>
> とすると、現在はちゃんと説明できない仕様なわけですよね。自然
> に期待されそうなことができず、警告もできないと言う。なら、
> curryそのものを削った方がよいかもしれませんね。どうせ、誰も
> 本気では使わないんだし。


ええと、「誰も本気では使わない」はおいといて (笑)

真に「ちゃんと説明できない仕様」なのは、ブロック引数を受け取る
ブロックが C で書けないことだと思います (Ruby では書けるのに) 。
つまり foo {|&b| ... } のような呼び出しが C では表現できません。



このせいで proc {|&b| body(&b) } のような proc が C で作れないのが
Proc#curry で問題になっているのですが、これは Proc#curry だけの話では
ないです。
例えば Method#to_proc や Symbol#to_proc がブロックを引き継がないのは
不自然だと思いますが、現状で修正は難しいはずです。たぶん。

"a".method(:upto).to_proc.call("c") {|x| p x }  #=> no block given

o = Object.new
def o.foo; yield; end
:foo.to_proc.call(o) { p 1 }  #=> no block given

さらに、[ruby-core:15927] でもこの話で困っている人がいるようです。
ブロック引数を受け取るブロックが普及したら、もっと大きな問題になる
可能性が高いと思います。



で、ささださんの 2) の案である ifunc の仕様変更が許されるのならば、
ANYARGS をやめればいいんじゃないでしょうか。

VALUE rb_iterate(VALUE(*)(VALUE),VALUE,VALUE(*)(ANYARGS),VALUE);

から

VALUE rb_iterate(VALUE(*)(VALUE),VALUE,rb_block_call_func*,VALUE);

に変更すれば、「2 については，今は rb_iterate に渡す関数ポインタの
引数が ANYARGS なので無理です」という問題がなくなると思います。

実際にこのように変更してみたところ、make 時に型整合性で大量の警告が
出ますが (これは修正可能) 、make test も make test-all も通りました。

-- 
Yusuke ENDOH <[e-mail]>