[ruby-dev:25830] Re: break & retry in block

原です。

ＸがＡならＹもＡだという言い方は分かり辛いですねすいません。

>まつもと ゆきひろです
>
>In message "Re: [ruby-dev:25822] Re: break & retry in block"
>    on Mon, 7 Mar 2005 14:52:04 +0900, Yukihiro Matsumoto 
><[e-mail]> writes:
>
>|1.9では(3)がエラーになっていますが、
>|これはバグだと思います。
>
>バグじゃありませんでした。1.9ではprocはcallがyieldと同じ働き
>をする(だからbreakは上にpropagateする)ようにしたのでした。し
>かし、作者も引っかかるということは、あんまり良くない仕様なの
>かなあ。

(1)と(2)関連では、f(&proc{break(0)}) は f{break(0)} と同じに
したらどうでしょう。つまり、break、retryはprocに対してではな
く、それを伴った(&で渡された)メソッドに対するものだと考える
わけです。たとえば

def f
  yield
end
def g
  b = proc{ retry }
  f(&b)
end
g

で、retryされるのはprocでもなくgでもなくfとしたらどうでしょ
うか。

これはprocをメソッドとして特別扱いしているように見えるけど、
実はそうではなくて、今までは

(A)  break（retry）はそのブロックを伴うメソッドをブレーク
  （リトライ）させる

と思っていたんだけれど、実は

(B)  break（retry）はそのブロックをyield（call）するメソッ
  ドをブレーク（リトライ）させる

のだったのだと解釈しなおせば大きな仕様の変更ではないのでは
ないでしょうか。proc内部ではyieldは無いので、後者の原理に
よれば、procをブレーク（リトライ）させないのは当然になりま
す。

中田さんのproc{}を{}と書けるようにしてしまう提案にも沿うよ
うな気もするし。


(3)と(4)関連では、先の(B)に従えば、

def f
  proc{break(0)}.call
  1
end
f

はfが0という値で返る、ということになるのですが、まつもと
さんの1.9での意図もこの考えと同じなのかな？

だとすると、retryも「上」のメソッドをリトライさせた方が統
一感があるような気がします。つまり

def f
  proc{retry}.call
end
g

では、リトライはprocの上のfから始まるべきではないかかと。

だからトップレベルでのproc{break(0)}.callやproc{retry}.call
はエラーということになる。

質問じゃなくて提案になってしまったけど、いかがでしょう。