(Reply-To: haskell-cafe)
Alastair Reid <[EMAIL PROTECTED]> writes:
>> 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.
> You're right, it can lead to late error messages. For e
> 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.
I think in this case, I'd prefer to use the IO monad.
1) It keeps the sequencing very, very explicit
and not likely to be confused
> > 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
> 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
On Mon, Jan 19, 2004 at 02:17:42PM +, Alastair Reid wrote:
> On Sunday 18 January 2004 15:42, Tomasz Zielonka wrote:
> > [much explanation of his option processing approach elided]
>
> Interesting technique - lots of cool ideas there.
Thanks :-)
> I too find getOpts to be a great base but ha
On Sunday 18 January 2004 15:42, Tomasz Zielonka wrote:
> [much explanation of his option processing approach elided]
Interesting technique - lots of cool ideas there.
I too find getOpts to be a great base but have taken a different
approach when writing console-mode Unix programs. Part of my
ap
rm is probably far from good, but I decided I'll
rather release it as it is than waste my effort.
I will highly appreciate your opinions and criticism for both technical and
literary side of this text.
High-level technique for program option
