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

apparently no way to implement --foo[=val] #243

Open
joeyh opened this Issue Feb 20, 2017 · 1 comment

Comments

Projects
None yet
2 participants
@joeyh

joeyh commented Feb 20, 2017

It's a fairly common pattern for an option --foo to set some default value, and --foo=val to set some more specific value. (With the equals sign being required before the value; a space is ambiguous in this case.)

I cannot find a way to implement this with optparse-applicative, without renaming one of the options from --foo to --bar.

This code compiles, and usage shows "[--foo ARG] | [--foo]", but parsing "--foo" fails.

data Foo = FooStr String | FooBool Bool

parser = (FooStr <$> strOption (long "foo")) <|> (FooBool <$> switch (long "foo"))

I don't really like that as a way of implementing it even if it worked, due to the redundancy.

Could there be a version of option that takes a default value, for when no value is provided?

(#242 touches on this, but is also about a regression)

@HuwCampbell

This comment has been minimized.

Show comment
Hide comment
@HuwCampbell

HuwCampbell Feb 20, 2017

Collaborator

Hi,

I agree it's not ideal.

We've been asked about this one a few times and have been cautious in supporting this due to ambiguity concerns amongst other things #235 #67 #109.

But I believe you are correct in that if you enforce that the option must be specified with an = then it will be unambiguously parse-able.

Without writing anything, I believe this will require a new entry in the OptReader sum type, and a new set of builders in order to use it.

Huw

Collaborator

HuwCampbell commented Feb 20, 2017

Hi,

I agree it's not ideal.

We've been asked about this one a few times and have been cautious in supporting this due to ambiguity concerns amongst other things #235 #67 #109.

But I believe you are correct in that if you enforce that the option must be specified with an = then it will be unambiguously parse-able.

Without writing anything, I believe this will require a new entry in the OptReader sum type, and a new set of builders in order to use it.

Huw

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