mainFromCmdParserWithHelpDesc is no longer required, because
peekCmdDesc can be used at the top-level to access the full
CmdDesc value. The knot-tying implementation is no longer
required either.
- monadic interface now uses two-phase setup: First step is to create a
full CommandDesc value, second is running the parser on input while the
CommandDesc is chained along
- applicative interface has a somewhat nicer/cleaner implementation, is
more secure by avoiding any demands on the API user that are not encoded
in types, but is slightly less expressive and requires ApplicativeDo to
get readable code.
- The applicative interface is *NOT* finished and the test-suite does not
cover it.
- Add the `traverseBarbie` construct which introduces a dependency on
the `barbies` library. This also effectively:
- Stop support for ghc < 8.4.
- Refactor the module structure a bit, and change the API of the central
`runCmdParser` function. It now returns a `PartialParseInfo`. Essentially,
`runCmdParser` is a combination of the previous `runCmdParser` and the
previous `simpleCompletion`. This API design is a curious advantage to
laziness: Returning a complex struct is harmless as fields that the user
does not use won't be evaluated. The downside is that the core function now
looks like a complex beast, but the upside is that there is no need to
expose multiple functions that are supposed to be chained in a certain way
to get all functionality (if desired), and we still _can_ provide simpler
versions that are just projections on the `PartialParseInfo`.
- Stop support for an anti-feature: The implicit merging of multiple
sub-commands definitions with the same name.
Lennart Spitzner
YAMAMOTO Yuji
Neil Mitchell