Neil Mitchell wrote: > I am pleased to announce CmdArgs v0.1. CmdArgs is a library for easy > command line argument processing - taking the arguments passed into > your program from getArgs and converting them into a structured value > for use in your program. Compared to the System.Console.GetOpts > library there are two key advantages: > > 1) The command line argument processors are shorter - in a typical > case they are about 1/3 the size, 90 lines with getopts vs 30 simpler > lines with CmdArgs (for HLint). > > 2) CmdArgs can support multiple mode command lines, such as those > found in hpc, darcs and cabal. > > The guiding principle of CmdArgs is to try and write each piece of > information only once, which makes the command line processing > shorter, and eliminates many of the accidental copy-and-paste style > bugs that are easy with getopts. CmdArgs requires GHC, but other than > this restriction, I do not foresee any reason for anyone to use > getopts over CmdArgs.
I very much like the general idea of this thing, but have a question regarding the interface. This is from the docs: (&=) :: a -> Attrib -> a Add attributes to a value. Always returns the first argument, but has a non-pure effect on the environment. Take care when performing program transformations. value &= attrib1 & attrib2 To expose an impure function (!) in an API, I don't know... I mean, couldn't one just wrap the value like this data Attributed a -- opaque (&=) :: a -> Attrib -> Attributed a mode :: Data a => Attributed a -> Mode a and thus retain a purely functional interface? Cheers Ben _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe