Conor McBride wrote: > Hi folks > > On 12 Sep 2007, at 00:38, Brent Yorgey wrote: > >> >> On 9/11/07, PR Stanley <[EMAIL PROTECTED]> wrote: Hi >> take 1000 [1..3] still yields [1,2,3] >> I thought it was supposed to return an error. > > [..] > >> If for some reason you want a version that does return an error in >> that situation, you could do something like the following: >> >> take' n _ | (n <= 0) = [] >> take' n [] | (n > 0) = error "take': list too short" >> | otherwise = [] >> take' n (x:xs) = x : take' (n-1) xs >> >> I'm not sure why you'd want that, though. The standard implementation >> gracefully handles all inputs, and usually turns out to be what you want. > > There are two sides to this form of "grace", though. I'll grant you, it's > quite hard to pull off a successful fraud without a degree of aplomb. > > I always hope that key invariants and hygiene conditions can be built into > the static semantics of programs, but where that's impractical somehow, I > prefer if the dynamic behaviour makes it as easy as possible to assign the > blame for errors. In such circumstances, I'd like operations to complain > about bogus input, rather than producing bogus output. >
Then you want a runtime assertion checking error helpful Data.List replacement. Could you use Control.Exception.assert and make a wrapper for Data.List? http://www.haskell.org/ghc/docs/latest/html/users_guide/sec-assertions.html _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe