Proposal: Command::Parserの改善 #551
Description
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)と解釈できるようにする