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