[#40528] [Feature #2833] 絵文字エンコーディングの提案 — Kenta Murata <redmine@...>

Feature #2833: 絵文字エンコーディングの提案

32 messages 2010/03/02
[#40530] Re: [Feature #2833] 絵文字エンコーディングの提案 — Yukihiro Matsumoto <matz@...> 2010/03/02

まつもと ゆきひろです

[#40597] Re: [ruby-list:46898] 重複組合せは組込みにならないのでしょうか? — "KISHIMOTO, Makoto" <ksmakoto@...4u.or.jp>

きしもとです

17 messages 2010/03/12
[#40598] Re: [ruby-list:46898] 重複組合せは組込みにならないのでしょうか? — Yukihiro Matsumoto <matz@...> 2010/03/12

まつもと ゆきひろです

[#40601] Re: [ruby-list:46898] 重複組合せは組込みにならないのでしょうか? — Yusuke ENDOH <mame@...> 2010/03/12

遠藤です。

[#40608] Re: 組込みの重複順列・重複組合せ — "KISHIMOTO, Makoto" <ksmakoto@...4u.or.jp> 2010/03/13

> 同様に、repeated_permutation/combination のデフォルト引数にも反対

[#40610] Re: 組込みの重複順列・重複組合せ — Yukihiro Matsumoto <matz@...> 2010/03/13

まつもと ゆきひろです

[#40641] [Bug #2965] method `===' called on hidden T_STRING object (NotImplementedError) — Kenta Murata <redmine@...>

Bug #2965: method `===' called on hidden T_STRING object (NotImplementedError)

12 messages 2010/03/15

[#40649] [Feature #2968] 数値の正負を返すメソッド — Yui NARUSE <redmine@...>

Feature #2968: 数値の正負を返すメソッド

17 messages 2010/03/15

[#40650] [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — Yui NARUSE <redmine@...>

Feature #2969: String#to_f が -h.hhh±pd を解釈できるように

38 messages 2010/03/15
[#40728] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — Tadayoshi Funaba <tadf@...> 2010/03/22

質問ですが、この形式は入力だけでなく、なんらかの方法で出力でも利用でき

[#40732] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — "NARUSE, Yui" <naruse@...> 2010/03/22

成瀬です。

[#40736] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — Tadayoshi Funaba <tadf@...> 2010/03/23

> String#to_f は従来から指数表記を許していたので、

[#40738] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — "NARUSE, Yui" <naruse@...> 2010/03/23

成瀬です。

[#40745] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — Tadayoshi Funaba <tadf@...> 2010/03/24

> to_i がデフォルトで prefix を見ないのは、0377 のような、

[#40747] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — "NARUSE, Yui" <naruse@...> 2010/03/24

成瀬です。

[#40749] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — Tadayoshi Funaba <tadf@...> 2010/03/24

> 先のパッチの対象関数が ruby_strtod である通り、

[#40759] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — "NARUSE, Yui" <naruse@...> 2010/03/25

成瀬です。

[#40762] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — Tadayoshi Funaba <tadf@...> 2010/03/25

> strtod(3) の解釈対象に含まれていない 2 進や 8 進を否定することが、

[#40763] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — "NARUSE, Yui" <naruse@...> 2010/03/25

(2010/03/26 3:05), Tadayoshi Funaba wrote:

[#40764] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — Tadayoshi Funaba <tadf@...> 2010/03/25

> なぜ同じなのでしょう。

[#40782] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — "NARUSE, Yui" <naruse@...> 2010/03/26

(2010/03/26 4:02), Tadayoshi Funaba wrote:

[#40786] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — KOSAKI Motohiro <kosaki.motohiro@...> 2010/03/27

>> strtod(3) を参考にしたり、影響されたりすることは普通にあるとは思います

[#40788] Re: [Feature #2969] String#to_f が -h.hhh±pd を解釈できるように — "NARUSE, Yui" <naruse@...> 2010/03/27

(2010/03/27 18:19), KOSAKI Motohiro wrote:

[#40695] keiju, please check tickets assigned to you — Yusuke ENDOH <mame@...>

いしつかさん

15 messages 2010/03/18

[#40779] [Feature #3018] UNINITIALIZED_VAR() マクロの導入 — Motohiro KOSAKI <redmine@...>

Feature #3018: UNINITIALIZED_VAR() マクロの導入

12 messages 2010/03/26

[#40805] Improvement of Fiber switching cost with system dependent way — SASADA Koichi <ko1@...>

 ささだです.

10 messages 2010/03/28

[ruby-dev:40866] Re: revert 1.9 \w limitation to ASCII

From: Yukihiro Matsumoto <matz@...>
Date: 2010-03-30 22:09:15 UTC
List: ruby-dev #40866
まつもと ゆきひろです

In message "Re: [ruby-dev:40863] Re: revert 1.9 \w limitation to ASCII"
    on Wed, 31 Mar 2010 02:39:18 +0900, "NARUSE, Yui" <naruse@airemix.jp> writes:

|「大きな非互換性になりそうです」というのは何か具体的なフィードバックが
|背景にあると思っているのですが、どのようなフィードバックでしょうか。

例によってソースをはっきり覚えていないので恐縮ですが、1.9で
\wがマッチしなくなったという苦情を見たことがあります。
Twitterだったかな。

|まず、EUC や SJIS に対してのものだと仮定します。

|また、EUC と SJIS 系のみというのは一貫性に欠けます。
|利便性のためなら一貫性を欠くこともいとわないのが Ruby の姿勢ではありますが、
|日本語系だけというのは正直いかがなものかと思います。
|というわけで、この方向で行くならば、non ASCII non Unicode の場合は、
|に変えた方がいいように感じます。

本人はそのつもりでした。今読み返すとそうは読めませんね。

|次に、Unicode、というか UTF8 に対してのものだと仮定します。ここで、
|> Unicodeにおいては、キャラクタデータベー
|> スがあるので、Unicode的にキャラクタなものを対象にするのが良い
|> と思います。
|を採用すると、すぐには気づきづらいが実際に問題が出るという、
|厄介な互換性問題を組み入れることになります。
|
|というのも、後に他の言語での \w の中身を出していますが、普通はこの
|「Unicode的にキャラクタなもの」は記号の類を含みません。
|ちなみに、Bug #3047 は一足早くそれを期待してがっかりしている例です。
|http://redmine.ruby-lang.org/issues/show/3047
|
|1.9 で \w を「Unicode的にキャラクタなもの」にするとこの逆、
|具体的には今までマッチしていた一部の文字がマッチしなくなります。
|これは non ASCII が全てマッチしなくなる (けどすぐに気づく)
|現在の実装よりたちが悪いのではないでしょうか。
|つまり、互換性が理由ならばこの案は無いと思うのです。
|
|まとめると、互換性が理由ならばエンコーディングに限らず、
|(とは言っても non dummy encoding になりますが)
|[a-zA-Z_0-9] + non ASCII (= /[a-zA-Z_0-9\P{ASCII}]/) が正解でしょう。
|Ruby の文法的にもこれは識別子に使える名前と一致するので意味が
|なきにしもあらずであるようには思います。

確かにここは議論の余地のあるところです。

まず、挙動の候補を

 (1) a-zA-Z_0-9
 (2) a-zA-Z_0-9 + non ASCII
 (3) Unicode的Caharacter

とします。次に、利用者の立場を

 (a) 1.8スクリプト移植者 (EUC/SJIS)
 (b) 1.8スクリプト移植者 (UTF-8)
 (c) EUC/SJIS(要するにUnicode以外)利用者
 (d) Unicoder

と分けます。これらそれぞれの立場にとって「望ましい」挙動とは

  (a) → (2) : 互換性が維持されるから
  (b) → (2) : 互換性が維持されるから
  (c) → (2) : 互換性が維持されるから
  (d) → (3) : おそらく本来\wに期待するところだから

になるでしょう。(d)以外にとっては、成瀬さんのおっしゃるよう
に、Unicodeも含めて a-zA-Z_0-9 + non ASCII にすべきという結
論になりそうですね。

しかし、今後、Rubyの利用者のうちUnicoderの割合は増加し、互換
性を強く期待する人は減少するであろうことを考えると、

 non Unicode → (2)
 Unicode     → (3)

というのは、さほど悪い選択ではないと思います。一方、現状の
a-zA-Z_0-9 に限定することは、全員が「しかたない」と感じるもの
の、多くがうれしくないという「平等に不満」というものになって
いるのではないでしょうか。

成瀬さんが指摘されるUnicodeにおける互換性問題とは、

  * Unicode利用者、かつ
  * \w が全てのnon ASCIIキャラクタにマッチすることを期待する

人に発生するものですが、これの深刻さはちょっとわかりません。
たいした問題ではなさそうな気もするんだけど。

|なお、互換性とは別に書きやすさの面で \w で単語構成文字っぽいのに
|マッチして欲しいという主張ならば別の議論で、以下のような感じになりますか。
|1. \w だけ特別扱いしたい
|2. \w だけ Unicode は気持ち悪い
|2a. [:word:] 使ってよ
|2b. \d と \s も Unicode 志向に戻そうぜ

ところで、[:word:]って現状なににマッチしますかね。なんとなく、
a-zA-Z_0-9にしかマッチしないような気がするんですが。[:word:]
が上で述べた挙動をするのであれば、私の抵抗はだいぶ少なくなる
んですが。

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

In This Thread