Joe Fasel, you wrote:
>
> I think Fergus's efficiency argument may be a red herring.
> Here is an excerpt from a compiler I wrote recently:
>
> > data JvlArgs = JvlArgs {optNoLink :: Bool,
> > optVerbose :: Bool,
> > jvlClassNames :: [String]}
> > deriving Show
> >
> > jvlArgs :: JvlArgs
> > jvlArgs = getJvlArgs (unsafePerformIO getArgs)
> > JvlArgs {optNoLink = False,
> > optVerbose = False}
> >
> > getJvlArgs :: [String] -> JvlArgs -> JvlArgs
> > getJvlArgs ("-c":ss) args = getJvlArgs ss (args {optNoLink = True})
> > getJvlArgs ("-v":ss) args = getJvlArgs ss (args {optVerbose = True})
> > getJvlArgs (s@('-':_):_) _ = error ("bad option: " ++ s)
> > getJvlArgs ss args = args {jvlClassNames = map internalClassName ss}
>
> Note that argv (= unsafePerformIO getArgs) is a constant (as is
> jvlArgs), defaults are dealt with systematically, error handling
> (not very extensive in this case) is done, and the arguments are
> scanned only once (lazily, in fact).
That's a lot better.
I'm still not entirely happy with the error handling, though.
As a general rule, I try to use `error' only for internal software
errors, not for error messages that can result from the user's
mistakes. (But perhaps that is another functional programmer's
death wish... what do other people think about this issue?)
Also, the fact that the arguments are scanned lazily is in fact
slightly worrying -- I hope your program is guaranteed to always
evaluate jvlArgs, since I don't think it would be a good idea to ignore
syntax errors in the command-line options just because you don't happen
to execute a part of the program that needs to examine them.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
