高橋征義です。遅ればせながら。

Tanaka Akira <akr / m17n.org> wrote:
> とりあえず pattern match 時に juxtaposition が associative である必要
> はありそうですが、あまりよくわかりません。
> 
> ちょっと Ruby で実装してみて頂けませんか? (嘘)

(^^;;;

> ふむ。character class 外の ] も警告したほうがいいかも。

 /a]/ とかでしょうか。これは警告してもいいんじゃないかと私も思います。

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

いやいや、それもちょっと違うんじゃないかと。
バランスを重んじるRubyとしては、「○×のやりかたを極める」と
いう発想が合わないと思うんですよ。それは○×をRubyとした場合
でも同様でしょう。Rubyらしさはたいせつですけど。

> > YEN SIGN そのものの字面はともかく、YEN SIGN がそれ以外の文字に
> > 紛れて多数入っていると、読みにくさが増すようです。
> 
> それは REVERSE SOLIDUS でも同じように思います。REVERSE SOLIDUS と YEN
> SIGN の違いによる影響は別の原因なんじゃないでしょうか。

うーん、どうなんでしょう。見た目の問題は慣れの問題だったり
するんでしょうかね。

> うーむ。算術式における優先順位に似たものではないんですか?
> 
>  ... + x * ... という式で、+ が右の要素を取り込む力と * が左の要素を取
> り込む力を比較すると、* の力の方が強いので x は * の引数になるわけです。
> 
> そういうような力じゃないんでしょうか?

解析結果自体は、優先順位によって決まるのではなく、なにかしら
決定的なルールがあって揺れがなく決まるようなもの、という
イメージなんです。

# とはいえ優先順位も「ルール」だろうとか、「暗黙の優先順位」が
# あるだけではとか言われると否定できないのですけど。

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

うーむ、それがあるのか。これは読みにくいですね。
そもそも「--」は読みにくいようです。フォントにもよりますが、
「-」「--」「---」の区別はつきにくいこともありそうです。

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

ルールからあらかじめ行列なりなんなりを計算しておいて、
それを利用してボトムアップに解析していく、というやり方が
違うように感じます。

# 単に順序の問題?  しかし「見やすさ」という意味なら
# 戦略の違いは無視できないんじゃないかと。

> なるほど。では、
> 
> [--abc]
> [ab%--]
> 
> も入れるとどういう順序になりますか?

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

です。「a-b-c」のような「どっちになるのか分からない」ほど
ではない(解釈としては[\--abc][ab%-\-]になりそう)けれど、
ちょっと勘弁してほしい、と感じます。

高橋征義 (TAKAHASHI Masayoshi)   E-mail: maki / rubycolor.org