This more of a style question, rather than a how to.
So I've got a program that needs two command line arguments: a string and an integer.
I implemented it this way:
main = do
args@(~( aString : aInteger : [] ) ) <- getArgs
let parsed@( ~[(n,_)] ) = reads aInteger
if length args /= 2 || L.null parsed
then do
name <- getProgName
hPutStrLn stderr $ "usage: " ++ name ++ " <string> <integer>"
exitFailure
else do
doStuffWith aString n
While this works, this is the first time I've really used command line args in Haskell, so I'm not sure whether this is a horribly awkward and unreadable way to do what I want.
Using lazy pattern matching works, but I could see how it could be frowned upon by other coders. And the use of reads to see if I got a successful parse definitely felt awkward when writing it.
Is there a more idiomatic way to do this?
I agree the
optparse-applicative
package is very nice. Awesome! Let me give an up-to-date example.The program takes as arguments a string and an integer n, returns the string replicated n times, and it has a flag which reverses the string.
Once the file is compiled (with
ghc
as usual):Now, assume you want an optional argument, a name to append at the end of the string:
Compile and have fun:
I suggest using a
case
expression:The binding in a guard used here is a pattern guard, a new feature added in Haskell 2010 (and a commonly-used GHC extension before that).
Using
reads
like this is perfectly acceptable; it's basically the only way to recover properly from invalid reads, at least until we getreadMaybe
or something of its ilk in the standard library (there have been proposals to do it over the years, but they've fallen prey to bikeshedding). Using lazy pattern matching and conditionals to emulate acase
expression is less acceptable :)Another possible alternative, using the view patterns extension, is
This avoids the one-use
aInteger
binding, and keeps the "parsing logic" close to the structure of the argument list. However, it's not standard Haskell (although the extension is by no means controversial).For more complex argument handling, you might want to look into a specialised module — System.Console.GetOpt is in the standard
base
library, but only handles options (not argument parsing), while cmdlib and cmdargs are more "full-stack" solutions (although I caution you to avoid the "Implicit" mode of cmdargs, as it's a gross impure hack to make the syntax a bit nicer; the "Explicit" mode should be just fine, however).These days, I'm a big fan of optparse-generic for parsing command line arguments:
As your program matures, you may want to come up with a complete help, and a well-annotated options data type, which
options-generic
is great at. But it's also great at parsing lists and tuples without any annotation at all, so you can hit the ground running:For example
Runs as:
There are plenty of argument/option parsing libraries in Haskell that make life easier than with
read
/getOpt
, an example with a modern one (optparse-applicative) might be of interest: