High-level technique for program options handling

[JP Bernardy]

> > 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.

I'm not certain this applies, but it should be
possible
to force evaluation order with a technique similar to
deepSeq. It might be cleaner than using IO.

http://www.haskell.org/pipermail/haskell/2001-August/007712.html

Cheers,
JP.

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus