4 ms·
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: [-R [-H
by jawher 12y ago
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:
[-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.
- jpdarago 12y agoFor that I think you can do something similar to what mpc for C (https://github.com/orangeduck/mpc https://github.com/orangeduck/mpc) and LPeg for Lua (http://www.inf.puc-rio.br/~roberto/lpeg/ 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.