[ruby-dev:3790] Re: List()

原です。

> 前田です。

> > そうですね。多分現状はyield(key, val)と書かれていると考え
> > ていいと思いますが、

> いや現状では配列を生成してからyieldに渡しているので、
> yield([key, val])と考えるべきだと思います。

Ｃのレベルでそういう雰囲気があるのでしょうね。同意します。
私の発言は yield(key, val) は yield([key, val]) よりタイ
プ量が少ないので使いやすい、程度の意味だと解釈してください。


> > |...これは[key, val]という一つの値を渡している
> > |わけではなくて、key, valという二つの値を渡すことを意図
> > |しているわけですから、
> > 
> > 意図はそうですね。配列を渡したいわけではなく、２つの
> > 値を渡したいんですね。それが出来ないので配列を「利用」
> > しているだけですね。
> 
> というよりも現在の仕様では、yieldには値の配列を渡す、という
> のが基本になっている訳ですよね。

同意します。私の同意したのは次の通り：

  現在の仕様において、複数の値を yield に渡す基本形は
  配列を作って引数にする方法である。yield(x, y) は 
  yield([x, y]) の省略形である。

同意も何も事実そのままか。

> > |{"key"=>"val"}.each_with_index {|key, val, i|
> > |  p key #=> "key"
> > |  p val #=> "val"
> > |  p i   #=> 0
> > |}
> > |
> > |となる方が、
> > |
> > |{"key"=>"val"}.each_with_index {|key, val, i|
> > |  p key #=> ["key", "val"]
> > |  p val #=> 0
> > |  p i   #=> nil
> > |}
> > |
> > |よりも自然だと思います。
> > 
> > 私も前者の方が自然だと思います。しかし現在の動作は後者である。
> > そして、将来も互換性を保つためにそれを守る事になると思います。
> 
> 僕が先のメールで示したeach_with_indexでは、Hash#eachで
> yield([key, val])としても、yield(key, val)としても、現在の仕様では
> 前者の動作になりますよね?
> 逆に原さんの提案が採用されるとyield([key, val])の場合は後者の動作に
> ると思います。

全くその通り。変だなあ、同意見が反論されている。(^^;;

私の望みは、each_with_index に前者の様な自然な動作をして欲しい
のではなくて、前者の様な自然な動作をするような each_with_index
が定義可能でありながら後者の様な動作をする定義になっている状態、
です。（ひねくれてるんじゃなくて互換性のため。）|(k,v),i| とい
う受け方もあるし。

で、前田さんは現在でも前者の様な動作をする each_with_index が可
能であると言うんですよね。これについては後に問題の形で述べます。

> > なぜ後者が現在の仕様であるかというと、それは現在の yield の仕
> > 様ではそれが最も実装がシンプルだからですね。(私の案が採用され
> > れば前者も同じぐらい実装はシンプルになります。)
> 
> これはeach_with_indexの仕様をどうするべきかという話で、
> yieldの値の渡し方の話とは別なのではないでしょうか。

私は each_with_index の仕様は yield の値の渡し方の仕様に
引きずられていると思っているので。これには異論が考えられる
けれど。

> 現在の仕様でも先の例の前者の挙動にしたければ、先のメール
> のようにeach_with_indexを変更すれば良いわけですし。

ここは反論がはっきりできると思うのだけど。先の、というのは
[ruby-dev:3743] で前田さんが書いた each_with_index2 の事
ですよね。でもこれは [[1]].each_with_index2 { |x| p x }
が [1, 0] になるのでまずいんじゃないかと、後で私は書きまし
た。それについては回答が無かったんだけど、重要な問題だとは
思われなかったんかな。改めて、、

問題：次の例のような動作するな Enumerable のメソッド
each_with_index3 の定義は何？

  [1, 2].each_with_index3 { |x|  #=> x = [1, 0]
                                     x = [2, 1]
  [[1], [2]].each_with_index3 { |x| #=> x = [[1], 0]
                                        x = [[2], 1]
  [[1,2], [3,4]].each_with_index3 { |x| #=> x = [[1,2], 0]
                                            x = [[3,4], 1]
　{1=>2, 3=>4}.each_with_index3 { |x| #=> x = [1, 2, 0]
                                          x = [3, 4, 2]

私は、現在の仕様では、レシーバ self の形による場合分けでしか
書けないと思います。


> 原さんの意見は、今回の仕様変更で実際には|*x|の挙動がかわるだけ
> だが、モデル的には、yieldからapply的な意味(こちらが歴史的には
> 本来の意味なのですが)を排除して、funcall的な意味に限定しよう、
> ということですね。

そうです。

> 僕が考えていたのは、基本的に配列とリストを区別しないというモデル
> が前提で|*x|の時だけ区別することになると、yield([1, 2])として複数の
> 値を渡すつもりだった人にとっては、上のeach_with_indexのような
> 場合に挙動が変わってきて困惑することになるし、逆に受け取る方として
> はリストではなく配列を受け取ったとしても、yieldした側が複数の値と
> して渡したかったのかもしれないというリスクがつきまとってしまう
> ということです。

ここははっきり意見が分かれました。私はその困惑とリスクは無いと
考えています。まず前者ですが、配列を複数の値で渡すつもりだった
人は、つまり funcall 的に使った人はパラメータを |x, y| と複数
で受けるか、|x| と一つで受けて x[i] を利用するでしょう。なぜな
ら、funcall 的であるときパラメータの数は決まっているか、さもな
ければ何番目の値が何を意味しているかそれぞれ理解しているはずだ
からです。つまり funcall 的に利用される yield を |*x| で受け
ることは現状では殆どないと考えます。

後者の受け手にリスクがあるという件ですが、イテレータの利用者は
そのイテレータについて知っているので問題ないのでは？従って複数
の値を配列で渡す状況では今でも私の案でもかえってまちがいが少な
い気がします。ただ、Enumerable の様なイテレータからイテレータ
を作るいわばメタ・イテレータの様な物はその限りにあらずで、相手
もが誰だかわからない。その場合は素通しできる私の案の仕様が有利
でしょう。

> 原さんのように配列を複数の値として渡せるのは互換性のためだけだと
> して、yieldで配列を渡しても複数の値と解釈されない場合があること
> を仕様で明示して、そのような動作を期待してはいけないことにすれば
> 問題ないと思いますが、そうすると配列で複数の値を渡せるという面
> は、メリットというよりデメリットになりますね。

互換性だけでなくそれは便利だから、、、

わからないなあ。仕様を明示する必要があるのはその通りだけど。複数
の値 1, 2, 3 を yield [1, 2, 3] と渡すのは全くＯＫですよ。受け
側がそれを知っていればね。現状でそれ（複数の値を配列で渡した事）
を知らずにイテレータを利用する例ってありますか？現状の方が仕様の
明示はより強く求められると思うけど。ただ、私の仕様ではもはや、
yield(1, 2, 3) は yield [1, 2, 3] の省略形ではないということは
はっきりさせておくべきですね。


哲学を言いますとね（前田さん相手になんと言うことを(^^;） Array 
というのは重要な機能がいくつかあるけど、その大きなものとして、
「複数のオブジェクトを表現する」というものがあります。だから複数
のオブジェクトを Array にして扱うのは本筋も本筋、超メインストリ
ームなわけです。しかしおもしろいことにこの方法だと複数のオブジェ
クトがまたオブジェクトである、という再起的な構造とかかわるわけ
です。それはメリットもあるしデメリットもある。デメリットを述べ
ると Array のオブジェクト一個ぽんと置かれたとき、それが本当に
１個のオブジェクトであるのか、複数のオブジェクトを表現している
かわからない。それを区別するためには他の情報が必要な訳です。ソ
ースコードとか仕様書とか。つまり情報の送り手と受け手が Array 
を利用するプロトコルでしゃべるかどうか判断するには、メタレベル
の手段であらかじめネゴシエートしないといけないのです。

一方私の List による方法は、通信手段が List で固定です。List 
というユーザーに見えない低層のプロトコルが固定されているので、
Array に乗せたときの様な混乱が無いわけです。そして前の Array
によって複数のオブジェクトを渡すのはいままで通りやればいい。た
だし List の上に乗った Array のオブジェクトを、ユーザーの定義
したプロトコルとして自由にしてください、という事で。実際に今ま
で通りしばしば利用される方法になると思います。

私には前田さんは List プロトコルの |*x| による復号は失敗して低
層がむき出しになるから危険だと言っている様に感じます。私はそれは
Array プロトコルより解像度が上がったのでノイズが目立つ様に感じ
ているだけで、それはノイズではなくて本来の姿です。気になるなら
フィルターをかければいい。つまり |x| や |x, y,..| で受ければい
い。

こういう比喩ってしばしば事態を見にくくするんだけど大丈夫かな。(^^;
いえ、前田さんは分かっていると思うのだけど。私のイメージを言う
ことが役に立つかと思って。

> 少なくとも標準ライブラリについては、配列で複数の値を渡すことを
> 期待したコードをすべて書き直す必要があるように思います。

変だなあ。私は書き直す必要があるライブラリは殆どないと思うのです
が、例えばどんな例がありますか？もちろんコンパイルし直す必要はあ
るでしょうが。:-)

> > 将来「なぜ each_with_index のブロックパラメータは x, y, i を
> > 出さずに [x, y], i を出して来るの?」という質問が出ると思いま
> > すが、それは歴的事情だと説明する事になるでしょう。
> 
> これはまた別の理由があったのではないでしょうか?
> # 前に議論があったような気がするんですが忘れてしまいました。

私も何かあった様な覚えがあるんだけど忘れちゃった。私の提案
だった様な気もする。(^^;

> 現状のモデルを変更しないとしても、each_with_indexの変更は
> できますよね?

難しいんじゃないかなあ。（each_with_index だけの問題ではないのだ
けど）ええとさしあたってさっきの問題に答えてもらえます？(^^;
＃お暇な時で結構ですから。(^^;;