[ruby-dev:20325] Re: [Oniguruma] intersection of char class

In article <5FD2F0CF7F5D7F44B00F36870B9E78B508DE5038@SBG-EX4>,
  [e-mail] writes:

> 今のところ実装しているのは、&&[...]だけです。
> 従って上記の例の場合は、以下のようにしか書けません。
>    [\0-\177&&[^\0-\037\177]&&[^()<>@,;:\\"/\[\]?={} \t]]

なるほど。

> &&[...]の結合は、以下のように解釈されます。
>
> [A&&[B]]                A and B
> [A&&[B]C]             (A and B) or C
> [A&&[B]C&&[D]]    ((A and B) or C) and D

Ruby の(文の) and, or と同じやりかたの優先順位ですね。

ただ、この場合、共通集合を意味する "&&" と和集合を意味する "" で左右の
オペランドのくっつきかたを比べると、和集合の方がくっついている(共通集
合はオペランド間に 2文字あるのに和集合は 1文字もない) ので、和集合の優
先順位をあげた方が自然じゃないかなぁ、と思います。

> 文字クラスの中で文字クラスをグループ化する[....]については、
> 現時点では実装する予定はないです。
> それが有用な場合でも、他の記述方法で対処してもらうしかありません。

うぅむ。許容範囲ではありますが、ちょっと残念です。

そのうち、文字クラスも

char = /[\0-\177]/
ctl = /[\0-\037\177]/
separators = /[()<>@,;:\\"/\[\]?={} \t]/

token = /[#{char}&&[^#{ctl}]&&[^#{separators}]]+/

というような展開がうまくいくように Regexp#to_s を変えること提案するこ
とをもくろんでいたのですが。
# i オプションの扱いがちょっと問題ですが。
-- 
[田中 哲][たなか あきら][Tanaka Akira]