Proposal: Command::Parserの改善

[GenKuzumochi]

Command::Parserについて3つ提案です。影響が大きいので、今後の拡張性含め慎重に議論したいです。

1. prefix_numberを演算可能にする

prefix_numberで計算を受け付けることで、余分なカッコを減らすことができる。
アサルトエンジン 現状では (1+2+3*3)AE45としなければならないが、1+2+3*3AE45が12AE45と解釈されるようになる。

-    notation: term NOTATION term
+    notation: add NOTATION term
            {
              raise ParseError unless @prefix_number && @suffix_number
              result = { command: val[1], prefix: val[0], suffix: val[2] }
            }
-           | term NOTATION
+          | add NOTATION
            {
              raise ParseError unless @prefix_number
              raise ParseError if @need_suffix_number
              result = { command: val[1], prefix: val[0] }
            }
            | NOTATION term
            {
              raise ParseError unless @suffix_number
              raise ParseError if @need_prefix_number
              result = { command: val[0], suffix: val[1] }
            }
            | NOTATION {
              raise ParseError if @need_prefix_number || @need_suffix_number
              result = { command: val[0] }

テスト通過します。1+2D6等と一貫性はなくなるものの、システム固有コマンドとして支障は無いかと思います。
register_prefix('\d*SG')などとなっている箇所を修正する必要があります。

2. 使っていないmodifierを各システムで無効にする

modifierはクリティカル等と違って現状デフォルトになっており、「ダイス目+固定値」などでよく使われる。
シノビガミ 2SG+5 (2SG+5@12#2) ＞ 7[2,5]+5 ＞ 12
一方で、modifierを使っていないシステムでも有効になったままのことが多い。（modifierが無視される）
アサルトエンジン 12AE45+100 (12AE45) ＞ 6 ＞ (16)成功 / (62)失敗

厳密には破壊的変更ですが、無視されているmodifierが使えなくなる影響に収まります。
modifierをデフォルトfalseにして、使うシステムだけでenable_modifierするにするのもありかと思います。

3. optionを演算可能にする

#や@の後ろでカッコなしの演算を可能とすることで、入力が簡単になり見やすくなる。また、ゆとチャ等のコマンドとの互換性が一部向上する。
シノビガミ　2SG+5@(12-1*2)#(2+1*2)　→　2SG+5@12-1*2#2+1*2

問題点

他のものと異なり、一貫性について影響が大きいです。

modifierの解釈と一部干渉する。現在の遷移表は以下のようになっている。

expr: notation option modifier target ← rule1
        | notation modifier option target ← rule2
        | notation option target ← rule3

• SG@12-1が、rule1についてSG@(12)-1なのか、`SG@(12-1)なのかが干渉する。
• SG-1@12-1はrule2になり、干渉しないため、こちらのパターンだけ省略可能とする
• SG+0@12-1とSG@12-1の解釈が異なるのが結構気持ち悪い
• 今後追加するシステムでは積極的にrule1の記法を廃止することで、SG@12-1をSG@(12-1)と解釈できるようにする

[ysakasin]

提案ありがとうございます。１と３の提案は却下します。いずれも、一般的な中置記法の原則から外れることになってしまうからです。特に１を許可してしまうと、 1+2D6 を 3D6 と扱わざるおえなくなり、他のコマンドと整合性が取れなくなってしまいます。

SG+0@12-1とSG@12-1の解釈が異なるのが結構気持ち悪い

こちらは SG+0@12-1 が許容されてしまうことがバグ的な挙動なので、SG+0@12-1 を許可しないように修正したほうがよいと思います。

[GenKuzumochi]

なるほど。個人的にはSG+1が1+SGと表記できないように、システム独自コマンドが中置記法との整合性を取る意味は薄いかと感じています。

ちなみに、中置記法の原則から外れず、「優先度の低い二項演算子」として解釈するパーサを追加するのはいかがでしょうか。（既存のコマンドは壊さない前提で）

高　D(加算ダイス)
　　*/
　　+-
低　CMD

1+2*3CMD1+2*3>=5を(1+2*3)CMD(1+2*3)>=5と解釈

特に、達成値を出さないコマンド(アサルトエンジンや獸ノ森、表の参照等)では2CMD6+1が(2CMD6)+1と解釈される余地がありません。「CMD固定値+直前の出目」のような、チャットパレットに登録できないコマンドを頻繁に使う場合、カッコが必要だとゲームテンポが悪化します。
簡便なパーサによって、新クトゥルフがCC2やCC+2はOKでCC+1+1は許容しないような、実装依存のゆらぎは低減できるのではと思っています。

こちらは SG+0@12-1 が許容されてしまうことがバグ的な挙動なので、SG+0@12-1 を許可しないように修正したほうがよいと思います。

こちらは提案3を導入した仮定なので、現状でSG+0@12-1は構文エラーとなります。

また、提案2のmodifierが無意味にONになっている箇所を時間があるときに探してみます。