[Haskell-cafe] Re: IO (Either a Error) question
uzytkownik2 at gmail.com
Sat May 8 01:30:30 EDT 2010
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.
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
 Well - what came to my mind is something like:
func :: Either a b -> Maybe b
func f = do Right x <- f
1. It's IMHO vary bad style as it silently fails in cases mentioned
2. It is not obvious knowing rest of Haskell. I expected until now a
pattern failure error.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: This is a digitally signed message part
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20100508/c164f8a6/attachment-0001.bin
More information about the Haskell-Cafe