そこはかとなく後者っぽい気がするぞ
LarkBox で前にビルドした UEFI でシェルギャス描くやつ起動したら落ちちゃったから UEFI ファームに実装されてないんだろうなこれ
で、根の側のパーサ (user 側) が Err(ErrMode::Backtrack(e)) を受け取って別候補を試すのが “正常” なら、そのときはそういうコンビネータ (alt() とか) を使うなり match を書くなりしろ、という感じ。
winnow の Result の分類は「(一番枝の部分のコードで) 続行するか離脱するか」で徹底している。 incomplete が正常系かどうかとかいう意味を考えるのではなく、「入力が足りないなら続行できないから (正常な挙動かどうかに関係なく) 脱出しやすくする」という感じ
declavatar でいうとほぼセマンティクスが正しいかどうかしか見てないのでこの中だと 基本 cut でたまに backtrace みたいな感じっぽそう
winnow crate (パーサコンビネータライブラリ) のエラー設計が参考になるかも。エラーが
* incomplete (続行するには入力が足りない)
* backtrace (パース失敗したので別の候補を試すべき)
* cut (他の候補を試さないレベルの確定的なパース失敗)
の3種類ある
CompileStatus<T, E>{ Success(T), Failure, Fatal(E) } を生やしたことで ? が使いづらくなってしまった……と思ったが、 recover() を生やしたので案外問題ないかも
@anatawa12 Generating (AacPlugin<T> は Generating Phase) より Transforming が必ず後に実行されるというわけでもないんでしょうかこれ(まあ別 Phase だったとしても依存関係が定義されていたほうがよさそうではありますが)