[darcs-users] [issue1550] general purpose command line parsing library (CmdArgs)
dagit at codersbase.com
Wed Sep 30 23:54:20 UTC 2009
On Wed, Sep 30, 2009 at 1:14 PM, Eric Kow <kowey at darcs.net> wrote:
> On Fri, Sep 18, 2009 at 16:16:29 +0100, Neil Mitchell wrote:
> > The underlying structure is that each command (mode in CmdArgs
> > terminology) takes a list of arguments drawn from a larger set of
> > arguments. You've optimised for parsing these options by keeping them
> > as an unstructured list. CmdArgs optimises for using these arguments
> > by having a real structure that can be properly queried. I would hope
> > that you replace your current options code with one using a proper
> > structure - since it will make your lives far easier.
> > The reason for all this effort is that you've flattened your flags,
> > which makes it harder to work with them, and guarantees you have
> > subtle bugs all over the place.
> Yeah, the lists are definitely a source of potential bugginess.
> I wonder: what if we just replaced [DarcsFlag] with Set DarcsFlag.
> Would that not achieve the intended effect as well?
I'm not certain, but I think a switch like this assumes that we have a
systematic way to combine multiple flags. Something akin to a monoid
instance. My understanding is that we initialize a [DarcsFlag] with some
defaults and then toss in more elements as we go, from places like the
command line. I bet we're not consistent about how we do the lookup and
"tossing in" when we add new values to the list. If I'm wrong this may be
easier than I'm thinking. I'm imagining that sometimes the later option is
an override and sometime it behaves as a combination.
I do get your point about query efficiency though. And I think you're right
that using Data.Set would provide good enough lookup performance. Well,
okay, I've never seen our queries of [DarcsFlag] show up in the profiling
data so I don't really feel like it's something that is worth optimizing.
> Largely irrelevant digression
> [Folding: search for "Back to Darcs"]
> It doesn't matter to me very much whether we use a record or some sort
> of list/set; I was mostly curious. If I may drop into random
> chattiness, in a program called GenI, I also use a list of flags
> approach (learning from Darcs).
> There are three advantages for me.
> 1. I can have people write GenI-like applications using the GenI
> library that have a subset of my flags and that add their own.
> 2. I can then group by flags into thematic sections like "Core options",
> "Input files", and "Optimisations". When I type geni --help, I
> automatically get the output broken down into sections with some
> flags appearing in more than one section (for example in both 'core
> options' and 'input files'). Darcs actually also does this to an
> extent with its 'Basic' vs 'Advanced' options.
> GenI only has one Mode in CmdArgs terms, but it's a big one!
> 3. Because I did not want to write getter/setter type functions like
> Also another disadvantage is that every time I look at this code, I get
> the feeling of really going about things in the most complicated
> Rube Goldbergesque way I could :-(
Interesting approach. Has anyone looked at the cabal-install source to see
how they tackle this problem? I recall a conversation once where Duncan was
telling me he's reasonably happy with the way resolving of defaults vs.
command line options works in cabal-install. So maybe they have something
worth stealing ideas from?
Hopefully I'm not off in left field here. I haven't really been following
the discussion, so if my comments don't seem to make sense, then they
probably don't :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the darcs-users