2008/10/17 allan
Hi Jeff
It sounds like maybe you just want an application that works a bit like 'cabal'. So with cabal the first argument is taken as the 'command' and then the rest are based on that:
cabal build --some other --options --which may --or --may --not have --arguments
Yi has a simple template for a script which should get you started, please find it attached.
So here instead of processOptions, you might want, processCommand
processCommand :: [ String ] -> IO () processCommand ("build" : args) = processBuildCommand args processCommand ("play" : args) = processPlayCommand args processCommand [] = putStrLn "You must supply a command" processCommand _ = putStrLn "Sorry I don't understand your command" --Probably out put help here as well
processBuildCommand :: [ String ] -> IO () processBuildCommand = similar to the processOptions except now you are sure you are in a 'build' command
you *might* even have a separate set of option descreptions for each command.
I wanted to throw in another idea, something I didn't come up with myself but used in omnicodec[1]. Now I don't remember where I picked up the idea: 1. Keep all option values as members of a type T 2. Define an instance of T with default values, dT 3. When using getOpt let the type of the options be something like [OptDescr (T -> IO T)] 4. To get the final set of values fold (>>=) over all the list of arguments returned from getOpt and using dT as the start value. Something like 'effectiveT <- foldl (>>=) dT arguments' In a tool I recently started working on I decided not to work in IO and instead I ended up with something like 'effectiveT = (foldl (.) id arguments) dT'. /M [1]: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/omnicodec -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe