Feature #2323: "Z".."Z".succが空

• Status: Closed
• Assignee: matz (Yukihiro Matsumoto)
• Target version: -

[hasari (Hiro Asari)]

=begin
surfboard:~$ ruby1.9 -v; ruby1.9 -e 'p ("Z".."Z".succ); p ("Z".."Z".succ).to_a'
ruby 1.9.2dev (2009-11-02 trunk 25625) [x86_64-darwin10.0.0]
"Z".."AA"
[]

"Z".succではなくてもうちょっと”離れた”ヤツをRangeの終わりとして指定すると"AA"はしっかりと入っています。

surfboard:~$ ruby1.9 -e 'p ("Z".."ZA").include? "Z".succ'
true

でも半端な”離れ”方ではいけません。

surfboard:~$ ruby1.9 -e 'p ("Z".."CA").include? "Z".succ'
false

to_aを介しても同様です。

surfboard:~$ ruby1.9 -e 'p ("Z".."ZA").to_a.include? "Z".succ'
true
surfboard:~$ ruby1.9 -e 'p ("Z".."CA").to_a.include? "Z".succ'
false
=end

[hasari (Hiro Asari)]

=begin
浅里です。

2009/11/2 Nobuyoshi Nakada [e-mail]:

なかだです。

At Mon, 2 Nov 2009 16:19:40 +0900,
Hiro Asari wrote in [ruby-dev:39604]:

surfboard:~$ ruby1.9 -v; ruby1.9 -e 'p ("Z".."Z".succ); p ("Z".."Z".succ).to_a'
ruby 1.9.2dev (2009-11-02 trunk 25625) [x86_64-darwin10.0.0]
"Z".."AA"
[]

こんなところでしょうか。

このパッチで件の問題は解決されていますが、ちょっと別なところで問題になるかもしれません。

このパッチを当ててみたところ、"Z".."a"は空です。1.8では["Z"]が返ってきます。

更に、
http://redmine.ruby-lang.org/issues/show/1891にあるように、
パッチ無しでは["Z", "[", "\", "]", "^", "_", "`", "a"]です。
これに対応したリビジョン（r24573）では加えて:Z..:aが認められていて、
それにはアスキー配列に則ったシンボルが含まれています。

個人的には"Z".succが"AA"であるならば、二つ以上の要素を持つ"Z"から始まるRangeは"AA"を含むべきだと考えます。
Rangeを半順序集合に定義するのも可能とは思いますが、特別な動きをする事があるのならば、
それは明確に書かれていないと混乱を招くと思います。

参考までに指摘しておきます。

--
Hirotsugu Asari

=end

[matz (Yukihiro Matsumoto)]

=begin
まつもと ゆきひろです

In message "Re: [ruby-dev:39622] Re: [Bug #2323] "Z".."Z".succが空"
on Tue, 3 Nov 2009 22:22:58 +0900, Hiro Asari [e-mail] writes:

|個人的には"Z".succが"AA"であるならば、二つ以上の要素を持つ"Z"から始まるRangeは"AA"を含むべきだと考えます。
|Rangeを半順序集合に定義するのも可能とは思いますが、特別な動きをする事があるのならば、
|それは明確に書かれていないと混乱を招くと思います。

文字列のRangeについては、

• 文字列の順序の定義が複数ある(辞書順とsuccによるもの)
• Rangeはsuccを使うが、これは半順序集合でいろいろ面倒

という事情があります。で、現在、ちょっと中途半端な状態になっ
てます。最終的な仕様を検討する時間(とやる気)が取れなくて。

現状

• 両端ともすべてASCII数字である場合には、数的な順序
• 両端ともASCII1文字である場合には、ASCII文字コード的な順序

になってます。で、このいずれにもあてはまらないケースの仕様は
正直確定してません。苦労してもあんまり使われなさそうだし。
ただ、

• 両端が共通の先頭部分を持ち、非共通部分がすべてASCII数字で
  ある場合には数的な順序

というのは採用しようと思ってます。あとは、ある文字列から別の
文字列にsuccの連鎖で到達できるかどうか簡易に判定できるのであ
れば、それに従って順序を処理すると良いと思うのですけど、でき
るんだっけか。

                             まつもと ゆきひろ /:|)

=end

[naruse (Yui NARUSE)]

=begin
成瀬です。

Yukihiro Matsumoto wrote:

まつもと ゆきひろです

In message "Re: [ruby-dev:39622] Re: [Bug #2323] "Z".."Z".succが空"
on Tue, 3 Nov 2009 22:22:58 +0900, Hiro Asari [e-mail] writes:

|個人的には"Z".succが"AA"であるならば、二つ以上の要素を持つ"Z"から始まるRangeは"AA"を含むべきだと考えます。
|Rangeを半順序集合に定義するのも可能とは思いますが、特別な動きをする事があるのならば、
|それは明確に書かれていないと混乱を招くと思います。

文字列のRangeについては、

• 文字列の順序の定義が複数ある(辞書順とsuccによるもの)
• Rangeはsuccを使うが、これは半順序集合でいろいろ面倒

という事情があります。で、現在、ちょっと中途半端な状態になっ
てます。最終的な仕様を検討する時間(とやる気)が取れなくて。

現状

• 両端ともすべてASCII数字である場合には、数的な順序
• 両端ともASCII1文字である場合には、ASCII文字コード的な順序

になってます。で、このいずれにもあてはまらないケースの仕様は
正直確定してません。苦労してもあんまり使われなさそうだし。

念のため補足しておきますと、
Range#each のマニュアルには succ を用いると書いてありますが、
String や Symbol の場合は実際には upto を呼んでおり、
String#upto は常には String#succ を呼んでいません。
上記のまつもとさんの説明は String#upto の説明になります。

言い換えると、Range#to_a から Range#eachが呼ばれ、
range_each 経由で String#upto に行っているので、
この問題は以下のように書き換えることが出来ます。

% ruby19 -ve'"Z".upto("AA"){|x|p x}'
ruby 1.9.2dev (2009-11-02 trunk 25632) [x86_64-freebsd8.0]

あとは、ある文字列から別の
文字列にsuccの連鎖で到達できるかどうか簡易に判定できるのであ
れば、それに従って順序を処理すると良いと思うのですけど、でき
るんだっけか。

ちょっと簡易とは言いづらい気がします。
先の中田さんのパッチだと "0 0" から到達できない "0 00" に対して、
upto が微妙に動いたりしています。
"0 0".upto("0 00"){|x|p x}

英数の間に非英数がはさまったり、非英数が繰り上がって英数に突入するケースは
なかなか難しいように思います。
一度きっちり考えて文書化しさえすれば、あとは実装するだけではありますが。

代替案として、常に succ を使うようにして、なんとなく動くようにしつつ、
とりあえず確実に停止するようにするという方法もありますかね。
中田さんのパッチはそのような趣旨であるようにみえます。

--
NARUSE, Yui [e-mail]

=end

[naruse (Yui NARUSE)]

• Category set to core
• Status changed from Open to Assigned
• Assignee set to matz (Yukihiro Matsumoto)
• Priority changed from Normal to 3

=begin
Ruby 1.9 Feature に移動した上で、優先度 Low にしておきます
=end

[mame (Yusuke Endoh)]

• Target version set to 1.9.2

=begin

=end

[znz (Kazuhiro NISHIYAMA)]

• Target version changed from 1.9.2 to 2.0.0

=begin

=end

[kosaki (Motohiro KOSAKI)]

これは勝手には閉じられないなあ。どこかで集中して議論するタイミングが必要かも

[yhara (Yutaka HARA)]

• Target version changed from 2.0.0 to 2.6

[mame (Yusuke Endoh)]

これはもう今の挙動ありのままで仕様と考えるほかないのではないかと思いますが、どうでしょうね。
次回の開発者会議ネタリストに入れておきました。

[matz (Yukihiro Matsumoto)]

もうちょっと放置。

Matz.

[mame (Yusuke Endoh)]

現状

両端ともすべてASCII数字である場合には、数的な順序
両端ともASCII1文字である場合には、ASCII文字コード的な順序
になってます。で、このいずれにもあてはまらないケースの仕様は
正直確定してません。苦労してもあんまり使われなさそうだし。
ただ、

両端が共通の先頭部分を持ち、非共通部分がすべてASCII数字で ある場合には数的な順序
というのは採用しようと思ってます。あとは、ある文字列から別の
文字列にsuccの連鎖で到達できるかどうか簡易に判定できるのであ
れば、それに従って順序を処理すると良いと思うのですけど、でき
るんだっけか。

というあたりをパッチとか作って検討進める人が出てくるその日まで放置。

[naruse (Yui NARUSE)]

• Target version deleted (2.6)

[mame (Yusuke Endoh)]

• Has duplicate Bug #13663: `String#upto` doesn't work as expected added

[mame (Yusuke Endoh)]

• Status changed from Assigned to Closed

#13663 でほぼ同様のチケットが close されたのでこちらも閉じます。