Fergus,
Quite right. I used "error" because I was lazy.
In fact, the lazy evaluation of the arguments is also a red herring,
because the compiler is in fact strict in argv. (How else does it
know what to compile?) All the flag arguments must be scanned
in order to retrieve "jvlClassNames jvlArgs".
I suppose that a better way to do this is something like this:
> getJvlArgs :: [String] -> JvlArgs -> Either JvlArgs String
>
> processedArgs :: Either JvlArgs String
> processedArgs = getJvlArgs argv JvlArgs {optNoLink = False,
> optVerbose = False}
>
> jvlArgs :: JvlArgs
> jvlArgs = case processedArgs of
> Left args -> args
> Right msg -> error ("mishandled arguments: " ++ msg)
Then the main IO monad of the compiler can check processedArgs
once when it picks up the list of class names and proceed with
compilation or yield an IO error. This scheme still avoids plumbing
jvlArgs through the rest of the compiler.
But I'm a lazy programmer. ;-)
At this point, I may be leaning more toward Lennart's position,
as I'm less convinced of how valuable the "convenience" is.
--Joe
Fergus Henderson wrote,
| 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.
Joseph H. Fasel, Ph.D. email: [EMAIL PROTECTED]
Technology Modeling and Analysis phone: +1 505 667 7158
University of California fax: +1 505 667 2960
Los Alamos National Laboratory postal: TSA-7 MS F609
Los Alamos, NM 87545
