
Luke Palmer wrote:
On Wed, Mar 12, 2008 at 4:45 PM, Donn Cave
wrote: Well, the problem inherently requires a certain order of evaluation. But if you will just handle pattern match failure in the IO monad, then you can write a simple functional expression of the problem instead,
let (i, s') = decodeInt s in let (v, _) = decodeInt s' in (i, v)
... where I think `i' can be evaluated without forcing unnecessary evaluation of v. It's clearer, and avoids unnecessary strictness!
Unless of course you don't have an IO monad handy.
The issue is that exception handling semantics do induce an order of evaluation for determinacy: if both functions in a composition throw an exception at some point (say in the 3rd element of a list they're generating), you need to decide which exception ends up being thrown, and to do that based on the lazy evaluation order would break referential transparency.
It bugs me a little how good Haskell is with laziness, but how bad it gets when you need laziness with a slightly different structure. I don't see any way it could reasonably be "fixed" if I were designing my own language, it's just unsettling.
Isn't this what "imprecise exeptions" were invented (and implemented in GHC) for? See http://research.microsoft.com/Users/simonpj/Papers/imprecise-exn.htm Cheers Ben