Update Common.hs to expose stepParser #259
Conversation
I'm not fundamentally opposed to exporting more functions, but this is a rather internal function, and it would be very strange to make it part of the public API. If I was going to export it, I would probably prefer to put it inside a module marked internal (still accessible, but not with just What are you trying to do that would require this? I may be able to help you find an alternative way. |
Thanks for responding so quickly! High level: I want a parser that consumes all arguments given and returns a successfully parsed object as well as the set of arguments it knew nothing about. i.e. More detail: I'd be happy to open an Issue to track making this happen if that's easier. By exposing |
Yep, I've seen things like this before and recently made changes to support it more easily. Have you considered or seen the ForwardOptions policy and its builder? This will run the parser, but allow any flags and options unknown to the haskell parser to be collected into a positional arguments reader. Your c program could then run over those afterwards. |
Ah, I didn't realize that flag existed. I've been working via stackage, which doesn't have |
It's slated in for the 0.14 release. Which should come next month. |
I'll close this then. |
Thank you! |
stepParser is useful in building an incremental parser. Without exposing this, one needs to copy nearly all the contents of Options.Applicative.Internal. This change would save me from copying hundreds of LoC and save me from depending on internals that are likely to change.