I'm currently using Neil Mitchell's cmdargs package [1]. How does your package compare to that?
Hi Simon, If you're using cmdargs and you're happy with it, you should certainly stick with it, as it certainly has many capabilities that multiarg does not, as well as being much better tested :) I examined cmdargs before writing multiarg; the main reason I decided to write something myself is because cmdargs offers no (apparent) way to create options that take more than one argument, such as "--pair thing1 thing2". Some programs do have options that really take more than one logical argument but, as far as I can tell, most of them resort to tricks such as putting both options in a single word and using characters such as : or = to delimit them. (mplayer is a good example of this.) I figure that the shell already does the hard work of splitting things into words, so the parser should be able to parse options that accept more than one word as arguments. multiarg aims to be modular, like a parser combinator library. By taking a few simple pieces you can build very complex parsers. For instance, there is no explicit support for multiple-mode commands (e.g. "darcs whatsnew", "darcs send", etc.) multiarg does not need such support because there are a couple of parsers (nextArg, nonOptionPosArg) that can be easily used to parse modes, arguments to options, or positional arguments. cmdargs does a lot of things that multiarg will never do--for instance, it creates help automatically and even creates zsh completions automatically. This is a nifty feature but I always find these sort of things frustrating and I would rather just write the help in a text editor. For a sample module that uses multiarg, see Pantry: https://github.com/massysett/Pantry/blob/master/Pantry/Parser.hs --Omari