Comment on Parsing command line arguments using a finite state machine and backtrackingComments−nine_k11yWhy write an FSM and backtracking explicitly? Use parser combinators, they basically do the same thing, just express it in a clearer, grammar-friendly way: http://theorangeduck.com/page/you-could-have-invented-parser...−jawher11yParser combinators would certainly have been easier for me, the library author but not necessarily so for the end user.Contrast how it is done now: [-R [-H | -L | -P]] [-fi | -n] [-apvX] SRC... DST With a parser combinator based approach: and( optional(and('-R', or('-H', '-L', '-P'))), optional(or( '-fi', '-n' ) ), optional('-apvX'), repeatable('SRC'), 'DST') And this didn't even handle the fact that options order is not important.−jpdarago11yFor that I think you can do something similar to what mpc for C (https://github.com/orangeduck/mpc) and LPeg for Lua (http://www.inf.puc-rio.br/~roberto/lpeg/), which is to provide the parsing machinery and write a small DSL with the same machinery for the users.
Comments
Why write an FSM and backtracking explicitly? Use parser combinators, they basically do the same thing, just express it in a clearer, grammar-friendly way: http://theorangeduck.com/page/you-could-have-invented-parser...
Parser combinators would certainly have been easier for me, the library author but not necessarily so for the end user.
Contrast how it is done now:
With a parser combinator based approach: And this didn't even handle the fact that options order is not important.For that I think you can do something similar to what mpc for C (https://github.com/orangeduck/mpc) and LPeg for Lua (http://www.inf.puc-rio.br/~roberto/lpeg/), which is to provide the parsing machinery and write a small DSL with the same machinery for the users.