On Fri, 13 Dec 2002, Fergus Henderson wrote: (snip) > and [slightly] reduced need to use Monads would be outweighed by the > drawbacks mentioned above, i.e. code bloat and compiler complexity.)
Ah - that's the impression I got from your earlier reply, too. (snip) > time-outs or user interrupts. But if `choose' is only catching > exceptions raised by explicit calls to "throw" or "error", then > I think it would be semantically OK, wouldn't it? (snip) That would actually be fine - I hadn't been hoping to catch errors that were things like user interrupts, which sound like they should be monadic anyway - just things explicitly thrown as you suggest. Admittedly, that is a rather important point that I should have made - I hadn't actually thought about errors caused by other stuff going on in the system and I completely agree that they should be wrapped in monads. Basically I was just wanting to replace some of the nastiness I have in code that passes two-tuples of (result, errors) around and has conditional statements to deal with backing up the functional call chain to deal with "error conditions". What the code is doing can safely be done completely without monads so I didn't want any monads to be in the top-level type signature: all the "errors" involved are all things that were noticed in normal computation by matching "otherwise" in a guard and whatever, not IO or anything. -- Mark _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe