High-level technique for program options handling

[Alastair Reid]

> I have a question about error reporting. You use 'error' quite often. I
> think that this can cause errors to pop up at strange moments during
> program evaluation. It this a real problem? I prefer reporting errors
> early in the IO monad. I think there is some trade-off involved, but I
> can't name it now.

You're right, it can lead to late error messages.  For example, if two output 
files are specified then the program might read its input, spend some time 
processing and only report an error after some considerable time has passed.  
(I haven't actually seen this happen but I'm sure it would.)

One reason for using error in functions like 'uniqueNoDefault' (which checks 
that a list has precisely one element and either returns it or prints a 
useful error message) is that I use this function both from the IO monad and 
from pure code.  I'm reluctant to duplicate the code just to avoid this.

But maybe I should put it in a monad anyway (and go back and 'fix' all 
non-monadic uses)?  The error messages produced are basically telling the 
user that they made a mistake so I must have just read some input from a 
file, the command line or the console.

(Another issue with error reporting is that I should probably print the 
'usage' message whenever flags are incorrectly omitted, duplicated, etc.  
This too suggests that tying the checks more tightly into command line 
parsing (as you do) would be a good idea.)

Thanks for your comments.

--
Alastair