-
Notifications
You must be signed in to change notification settings - Fork 114
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
hang when providing default for [String] arguments #53
Comments
Thanks for the report. The problem is that arguments str (value "foo") behaves like many (pure "foo") when given an empty command line. The latter parser clearly hangs, because it's trying to return an infinite list of "foo" values (and it's not lazy enough to do it successfully). Now, I could try to fix the To get the behaviour you expect, you can use something like: some (argument str idm) <|> pure ["foo", "bar"] |
i get the same hang even for non-empty command lines. apparently the same reasoning applies to arguments1 as well. why is an infinite list the right semantics for value? what was wrong with the 0.5.2.1 behavior? i'd like you to keep arguments(1) with a sensical value modifier (i understand if it has to take a String rather than [String], but 0.5.2.1's [String] was most convenient and intuitive), since i can't (easily?) hand-roll a parser that has all the right effects (for instance, stating the default value in the help). |
Sure. I wasn't trying to say that it only hangs for empty command lines, just that the equivalence above holds when the command line is empty.
An infinite list is the right semantics of
I don't understand this complaint. What is wrong with what I suggested above? some (argument str idm) <|> pure ["foo", "bar"] |
that's a statement of exactly why arguments /= many . argument. an
special cases in the implementation? i didn't see an api change other than
that won't have the pretty effect of automatically showing the default |
Yes, and you can express it with
Yes, I was referring to special cases in the implementation. The API is also more consistent now (after the deprecation of
Ah, that's a fair point. You can always specify it manually in the help text, though. I'll reopen the issue for now, but I'm not sure if there is a clean solution. |
|
I just tripped over this as well. There's no way I would have figured out the workaround idiom you describe. At the very least I'd encourage you to describe it with loud shouting WARNING exclamations in the Haddock documentation, but the idea that the "default" isn't the default for values in an array (which can't happen, because you specified at least one to trigger that code path) really doesn't make any sense; default is for when the user didn't specify the option. I'm just lucky I found this bug here; I was about to give up on optparse-applicative. AfC |
I don't quite get the work around presented here. I have written the parser using the alternative instance something like this:
How would I apply the workaround here? |
Just remove the default value for |
You mean something like this?
|
No, I meant I'm not sure why you want a default there, it doesn't really make sense. If the option is missing, then it will just not be included in the resulting list. As you wrote it, it will return an infinite list with a tail of |
Well, I have a flag which have an optional argument. I'm currently rewriting a command line parser written simply by pattern matching [String] from getArgs. In this there is an option which if it have no argument should default to "Main.main", when it have an argument then use that one, if not even specified the flag should not occur in the resulting list. |
Optional arguments to regular options are not supported (#67). You can use a different option, though: many $
flag' A (short 'a')
<|> (D <$> strOption (short 'd'))
<|> (flag' (D "foo") (short 'e')) Would that be acceptable? |
Thanks for clarifying, that will be acceptable. :) |
wait wait wait we left this open cuz of the discussion in 2013 -- the 2014 discussion doesn't resolve those issues! |
Ok |
I've just added a warning regarding |
0.5.2.1 design was good, the change makes the api inconsistent (requires unintuitive workaround) and prevents nice handling (eg, auto display of the value in the help) for default values that happen to be lists. (it's been a long time, so i don't remember the details, but that's the flavor) |
in 0.5.2.1 i could have a ["string with spaces", "another one"] default for an arguments str. now in 0.7.0.2 that doesn't compile, i have to have ""string with spaces", "another one"", but that hangs (on one computer, another OOM's) when i execParser it!
also, it wasn't clear from the docs that i can't use auto for [String] arguments, took me a while to figure out i had to use str...
The text was updated successfully, but these errors were encountered: