On Fri, 2010-05-07 at 19:26 -0700, John Meacham wrote:
On Fri, May 07, 2010 at 08:27:04PM -0400, Dan Doel wrote:
Personally, I don't really understand why unfailable patterns were canned (they don't seem that complicated to me), so I'd vote to bring them back, and get rid of fail. But hind sight is 20/20, I suppose (or perhaps there exist cogent arguments that I haven't heard).
What counts as unfailable?
(x,y) probably, but what about
data Foo = Foo x y
If we don't allow it, we add 'magic' to tuples, which is a bad thing, if we do allow it, there are some odd consequences.
adding another constructor to Foo will suddenly change the type of do notations involving it non locally. said constructor may not even be exported from the module defining Foo, its existence being an implementation detail.
All in all, it is very hacky one way or another. Much more so than having 'fail' in Monad.
John
Sorry I'm asking but why: do Constructor x y z <- f g x y z is not compiled into: f >>= \(Constructor x y z) -> g x y z Hence using exactly the same way or reporting errors as pure functions? I.e. why fail !== error[1] Regards [1] Well - what came to my mind is something like: func :: Either a b -> Maybe b func f = do Right x <- f return x But: 1. It's IMHO vary bad style as it silently fails in cases mentioned above. 2. It is not obvious knowing rest of Haskell. I expected until now a pattern failure error.