[Haskell-cafe] Re: IO (Either a Error) question

Maciej Piechotka 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.
> 
>         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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
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 mailing list