Open BebeSparkelSparkel opened 1 year ago
I think this makes sense, seems like a reasonable approach.
I have created a simplistic working example https://github.com/BebeSparkelSparkel/commander-cli/blob/generics/src/Options/Commander/Generics.hs
What do you think?
One problem I am having is how to allow for descriptions.
Perhaps there could be a type like newtype Description (d :: Symbol) a = Description a
, but that seems invasive.
Or a type family Description (datatype :: Symbol) (module :: Symbol) (package :: Symbol) (fieldName :: Symbol) :: Symbol
that would resolve to the description.
I honestly wouldn't mind the newtype at all, I think that's quite helpful. Looks like it's on the right track, but I'm concerned about all of them being arguments rather than options and so on. Another thing to keep in mind is that this functionality is already very easily implemented by optparse-generic and I'm not so sure I want to encourage people to use this package for this functionality when its (arguably) better implemented in that package.
I'd be happy to help plug away at a patch which implemented this functionality well, but I'd be more likely to push it up to hackage if we:
Looks pretty doable from your code though, appreciate the example.
Thanks for the optparse-generic link. I'll look at that carefully. It might be the better option.
I find to be filling in a lot of record fields from the cli parameters and it would be much faster to have some generic way of generating parser code.
Which
genericOptions @("--" ++) @ID @(AB Maybe)
would generate something likeThere seems like there could be several versions for Opt Arg Flag. Does this make sense or is there a better way?