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

前田です。

In message "[ruby-dev:3788] Re: List()"
    on Thu, 10 Dec 1998 02:56:40 +0900,
Shin-ichro Hara <[e-mail]> wrote:

> |原> でもせっかくのアイデアなのにケチつける？:-)
> |
> |ケチをつけるというわけではないのですが、
> 
> いえ、せっかくのアイデアというのは x,y=[1,2] #=> x=1; y=2 とい
> うまつもとさんのアイデアのことで、私の *x= のアイデアであ、じゃ
> なかった、では、ないです。私のは十分にケチをつけてもらわないと。
> (^^;

あ、すみません、読み違えてました(^^;


> |...やはり配列とリストを
> |区別する/しない、というのは、どちらかに統一すべきような気が
> |しています。
> |
> |each_with_indexを
> |
> |    def each_with_index
> |      i = 0
> |      each { |*x|
> |        yield(*(x + i))
> |        i += 1
> |      }
> |    end
> |
> |のようにパラメータを展開して渡すようにしたとします。
> |
> |とすると、現状のHash#eachではyield([key, val])としている
> |わけですが、...
> 
> そうですね。多分現状はyield(key, val)と書かれていると考え
> ていいと思いますが、もし私の案が仕様になれば、以前と同じ
> 動作をさせるためにはyield([key, val])と書き直さなければな
> らないです。

いや現状では配列を生成してからyieldに渡しているので、
yield([key, val])と考えるべきだと思います。
# Listが導入されたらassoc_new()を書き換えればよいので
# yield(key, val)への変更は容易だと思いますが。

> |...これは[key, val]という一つの値を渡している
> |わけではなくて、key, valという二つの値を渡すことを意図
> |しているわけですから、
> 
> 意図はそうですね。配列を渡したいわけではなく、２つの
> 値を渡したいんですね。それが出来ないので配列を「利用」
> しているだけですね。

というよりも現在の仕様では、yieldには値の配列を渡す、という
のが基本になっている訳ですよね。

> |{"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])の場合は後者の動作に
ると思います。

> なぜ後者が現在の仕様であるかというと、それは現在の yield の仕
> 様ではそれが最も実装がシンプルだからですね。(私の案が採用され
> れば前者も同じぐらい実装はシンプルになります。)

これはeach_with_indexの仕様をどうするべきかという話で、
yieldの値の渡し方の話とは別なのではないでしょうか。
現在の仕様でも先の例の前者の挙動にしたければ、先のメール
のようにeach_with_indexを変更すれば良いわけですし。

> ここまではほぼ完全に同意できるわけですが、

というわけで、まだ合意に至ってないようですね。

> ここが良く分からないです。分からないからちゃんと返答できなくて、
> 一方的に自分の意見を述べてそちらが私が何が分からないのか汲んで
> くれる事を期待することになるわけ(^^; ですが 、、、

なんとなく意見の違いがわかったような気がします。

> 私の案が仕様になった場合は、配列を渡したい時は yield に配列を
> 渡し、複数の値を渡したい時は yield にリストを渡します。それが
> プログラミングの作法となるわけで、自然な作法だと思います。で、
> それはどちらであっても多くの場合同じ効果しか生まないのですが、
> たまに (新しい)each_with_index の様に差が出るわけです。
> 
> 現在までに書かれているイテレータ定義の多くはそれを区別しない
> で書かれていて、その意図がどちらであるのかイテレータの利用者
> は分かりません。本来はイテレータの作者に新しい仕様向けに書き
> 直してもらわないといけないわけです。書き直してもらうと、いい
> こと(利用者の料理のレパートリーが増えるということ)があるわけ
> です。

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

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

原さんのように配列を複数の値として渡せるのは互換性のためだけだと
して、yieldで配列を渡しても複数の値と解釈されない場合があること
を仕様で明示して、そのような動作を期待してはいけないことにすれば
問題ないと思いますが、そうすると配列で複数の値を渡せるという面
は、メリットというよりデメリットになりますね。
少なくとも標準ライブラリについては、配列で複数の値を渡すことを
期待したコードをすべて書き直す必要があるように思います。

> 将来「なぜ each_with_index のブロックパラメータは x, y, i を
> 出さずに [x, y], i を出して来るの?」という質問が出ると思いま
> すが、それは歴的事情だと説明する事になるでしょう。

これはまた別の理由があったのではないでしょうか?
# 前に議論があったような気がするんですが忘れてしまいました。
現状のモデルを変更しないとしても、each_with_indexの変更は
できますよね?

> |まつもとさんのご指摘のように哲学科なのですけどよいですか? (^^;
> 
> 前田さんがフランス哲学なのは前の第-1回 Ruby Conference で知っ
> ています。

あ、覚えててくださっていたのですか。
ありがとうございます:-)

> |「システムにとって意図とは何か」という題目で、ルーマンの社会
> |システム理論とアンスコムやデイヴィドソンの行為論を扱っています。
> 
> それって仏哲ですか?アメリカの社会学の様な感じ。:-)

なので仏哲専門の先生から指導教官が変わってしまいました(^^;

> 「システムにとって意図とは何か」うーむ興味深い。次の Conference
> では是非ご高説を賜わりたいです。(^^

いやいや、とんでもないです(^^;;;
# そういえばまつもとさんが京都にくるのはいつでしたっけ。

---
前田 修吾