Luke Palmer wrote: > On Wed, Mar 12, 2008 at 4:45 PM, Donn Cave <[EMAIL PROTECTED]> 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
