高橋征義です。

自分がどのように正規表現やその他のコードの字面を読み、理解して
いるのかというのは、自分自身でもよくわからなかったりします。
が、内省を駆使して自分なりに言葉にしてみます。

# 似非認知科学っぽくなっているかもしれませんが、ご容赦をば。

人間が脳内構文解析を行う場合、計算機のように一文字ずつ字句解析
→tokenごとに構文解析、という流れで行ってはいないように思います。
むしろ、Prologのように;-)、なんらかの条件によるマッチングを
行い、それができる場合は先に進めたり、場合によっては後戻りを
したり、という風に進めていっているように感じます。
# もちろん人間はProlog処理系ではないので、上から順にパターン
# を適用していくわけではないです。Guardの記述力が強力で、
# できるだけ分岐しないようなGuarded Horn Clauseみたいな感じ？(謎)

さて、正規表現を解釈していく場合、個々の文字を見る前に、
まず丸カッコ「()」やカギカッコ「[]」によって、おおざっぱな
tokenizeを行いたくなる気がします。この時、カッコの前に
「\」がついていれば、それはこの段階のtokenizeに使うカッコ
ではない、ということになります。さらに、「()」は入れ子になる
が、「[]」は入れ子にならない、というルールも脳内に働いて
います。
ここで「[a-z-]]」という記号列があったとします。この場合、
「[a-z-]」と「[a-z-]]」とでルールが適用される条件が複数ある
ので、どっちのルールを適用するかを迷ってしまいます。これが
「ちかちかする」という表現の意味、でしょうか。

次に「[a-z-]」が与えられた場合、「[]」の中を見ていくわけです
が、この場合に「]」はすでに使われているので、「z-]」という
範囲指定は考慮されません。いや、バックトラックする可能性も
ありますが、「先頭と末尾の-は別扱い」という脳内ルールが
ストレスなく適用されるので、この場合はバックトラックしません。

こんな感じでしょうか。うーむ胡散くさい。

Tanaka Akira <akr / m17n.org>さん wrote:
> > 一方、/[a-z-]/ の「読みにくさ」は、1)の意味ではあまり問題なさ
> > そうですが、
> 
> なぜですか?
> ここで、なぜ、z から ] までとは解釈しないのでしょうか?
> /[a-z-]]/ ならどうでしょうか?

上での説明の通りです。

> > これはRubyの
> > 変数のルール、先頭に「$」があると読みにくく感じられるので
(略)
> > かと思います。
> 
> そういう立場はあるでしょうね。というか、そういうのが Ruby 的な立場なの
> かも知れません。

とはいえ、空白sensitiveな文法や多重代入での教訓から、「凝りはじめると
どんどん複雑になる(のでほどほどにしておいた方がいいかも)」というのも、
(弱気な)Ruby使いの立場に感じます。

> > というわけで、今回の読みにくさに関しては、2)と3)のバランスの
> > 問題になるんじゃないかと。
> 
> バランスをどこにとるかということですね。

そうですね。
さらに、読みやすさ以外にも、書きやすさや過去との互換性を含めた
大きなバランスもありますし。

> 作業前に言うためにはまつもとさんが取り込むと発言するよりも更に前である
> 必要があったので、そうするのはほぼ不可能だったと思います。

あ、なるほど。

> > # あ、Windowsで見るとUNIXよりも「\」の見づらさが
> > # 増すような気がします。
> 
> REVERSE SOLIDUS よりも YEN SIGN のほうが「ごちゃごちゃしている」からで
> すか?

YEN SIGN そのものの字面はともかく、YEN SIGN がそれ以外の文字に
紛れて多数入っていると、読みにくさが増すようです。

> > その点、[a-]の「-」は、両端に文字を欲する力がそれほど強く
> > ないように感じます。実際、[]の外の「-」は、エスケープされ
> > ないわけですし。
> 
> この「文字を欲する力」には興味が湧きます。冒頭の「z から ] まで」とい
> う話とも関係するわけですが、もう少し詳しく説明して頂けませんか。

上の説明が説明になっているといいんですが。
「欲する」というのはルールに感情移入している見方でちょっと
わかりにくそうだったので、上記説明ではそういうのは排して
記述してみました。

> また、^ が左右に文字を欲する力はどの程度だと思われますか?

左右ですか？  それはないです。「[」の右に「^」があるケースは
別ルールになってます。が、それは「[]」のルールが適用された
後に適用されます。

> さらに、[^-] や [^-a] についてはどう思いますか?

[^-] は別にいいんですが、[^-a] はちょっと見づらいですね。
「[-」と「-]」という文字列の場合のみ例外、というつもりになって
いるのかも。

> # できれば演算子順位構文解析の、点がついた <, =, > との関連も尋ねてみ
> # たい所ですが...

「点がついた <, =, >」って「・＞」みたいなやつでしたっけ。
parse戦略が違う(演算子順位行列や順位関数を作っているわけ
ではない)ので関連はなさそうな気もしますが、気がするだけ
かもしれません。

> あと、
> 
> [-abc]
> [^-]
> [abcd-f-hijk]
> [abc-]
> [^-abc]
> 
> というので読みやすさに順序をつけるとしたらどういう順序にしますか?

(↑読みにくい)
 [abcd-f-hijk]        
 [^-abc]
 [-abc], [^-], [abc-]
(↓読みやすい)

です。やっぱり「-」は「[」か「]」にくっついていてほしい。

高橋征義 (TAKAHASHI Masyoshi)  maki / rubycolor.org