I'd say leave it to the application. The typical method I use for GetOpt is something along the lines of (untested code follows, but the intention shoudl be clear):
data Config = Config { verbosity :: Int, some_path :: String, }
emptyConfig :: Config emptyConfig = Config { verbosity = 1, some_path = "" }
options :: OptDescr (Config -> Config) options = [ Option "v" ["verbosity"] (ReqArg (\s c -> c { verbosity = read s}) "#") "...", Option "o" ["output"] (ReqArg (\s c -> c { some_path = s }) "DIR") "..." ]
...
main = do ... let (opts, nonopts, errs) = getOpt Permute options args let config = foldl (flip ($)) emptyConfig opts
and alternatively you could use 'foldr ($) emptyConfig opts' to get option processing in the other direction. If you want to make sure that an option is only used once, you can change the ReqArg argument in, say, "output" to soemthing like:
... ReqArg (\s c -> if some_path c == "" then c { some_path = s } else error "bad path")
or something like that. my $0.02. -- Hal Daume III "Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume On Tue, 18 Feb 2003, Sven Panne wrote:
[ Redirected to libraries list, because it is probably the right place to discuss System.Console.GetOpt ]
Will Partain wrote:
[...] While you're thinking about it, you might want to clarify the behavior of GetOpt in a few weird cases, e.g.
* duplicates of no-arg options are OK; e.g.: --foo --foo
* duplicates of with-arg options is bogus; e.g.: --foo-file=/etc/foo --foo-file=/etc/bar
(but what about? --foo-file=/etc/foo --foo-file=/etc/foo)
and others you can no doubt think of easily.
Hmmm, I'm not sure if there is a one-size-fits-all solution for this, e.g. think about a -v no-arg option, where one -v means "verbose", two -v mean "very verbose", three -v mean "ridiculously verbose" etc. Even for with-arg options an accumulating behaviour can make sense, e.g. for specifying multiple input files.
What do other people think about this issue? Should the handling of these cases be left to the application or should we take some special measures in the library itself?
Cheers, S.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries