[Haskell-cafe] Terminal-like Application Design
magnus at therning.org
Fri Oct 17 05:06:15 EDT 2008
2008/10/17 allan <a.d.clark at ed.ac.uk>:
> 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. 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
Magnus Therning (OpenPGP: 0xAB4DFBA4)
magnus＠therning．org Jabber: magnus＠therning．org
http://therning.org/magnus identi.ca|twitter: magthe
More information about the Haskell-Cafe