New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Common.hs to expose stepParser #259

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
2 participants
@JonCoens

JonCoens commented Apr 24, 2017

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.

@HuwCampbell

This comment has been minimized.

Collaborator

HuwCampbell commented Apr 25, 2017

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 import Options.Applicative).

What are you trying to do that would require this? I may be able to help you find an alternative way.

@JonCoens

This comment has been minimized.

JonCoens commented Apr 25, 2017

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. :: ParserInfo a -> IO (a, [String])

More detail:
I'm running in a mixed-language environment (Haskell + C++) where command-line flags are defined and processed in different places. Instead of users needing to remember which is a Haskell flag or a c++ flag, I'd rather have one of the parsers be smart enough to consume only what's required and give back the remaining set. This boils down to not failing when coming across an unrecognized flag. Having a required flag missing or giving a flag the wrong type are still grounds for quitting.

I'd be happy to open an Issue to track making this happen if that's easier. By exposing stepParser I can mimic parts of execParser that do what I want. I attempted making the changes I need (just a 2 line change to runParser), but it has some cascade effects into the test framework that I haven't been able to figure out.

@HuwCampbell

This comment has been minimized.

Collaborator

HuwCampbell commented Apr 26, 2017

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.

@JonCoens

This comment has been minimized.

JonCoens commented Apr 27, 2017

Ah, I didn't realize that flag existed. I've been working via stackage, which doesn't have ForwardOptions in it. From the description that sounds like what I'd be looking for!

@HuwCampbell

This comment has been minimized.

Collaborator

HuwCampbell commented Apr 27, 2017

It's slated in for the 0.14 release. Which should come next month.

@HuwCampbell

This comment has been minimized.

Collaborator

HuwCampbell commented Apr 27, 2017

I'll close this then.

@JonCoens

This comment has been minimized.

JonCoens commented Apr 27, 2017

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment