On 15/12/2010 04:01, Jonathan Geddes wrote:

Fail can't just be removed. That would just break too much code. For example, I find myself writing code like the following:

...

[a,b,c]<- Just someList

in place of

...

let [a,b,c] = someList

so that pattern match failure is "lifted" into the maybe monad (as long as I'm already in the maybe monad).

I would like to see a MonadFail class, with one method 'fail', such that it is a compile-time error to try 'failable' pattern matches in a monad that is not an instance of MonadFail.

--Jonathan

Perhaps pattern match failures in a MonadPlus should bind to mzero - I believe that this is what your example and similar wish to achieve. I've updated http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal to mention this. Does anyone know why fail and Pointed (in the paragraph "This would eliminate...") aren't beginning a new paragraph? They are both preceded by a blank line in the wiki source.

Any refutable pattern match in do would force MonadFail (or MonadPlus if you prefer). So 1. (MonadFail m) => a -> m a, \ a -> return a 2. (MonadFail m) => m a, mfail "..." 3. (MonadFail m) => Maybe a -> m a, \ a -> case a of Nothing -> mfail "..."; Just x -> return x 4. (Monad m) => a -> b -> m a, \ a b -> return a 5. (Monad m) => (a, b) -> m a, \ (a, b) -> return a As far as type inference and desugaring goes, it seems very little would have to be changed in an implementation. -- Lennart 2010/12/15 Tillmann Rendel

Hi John,

John Smith wrote:

...

Perhaps pattern match failures in a MonadPlus should bind to mzero - I believe that this is what your example and similar wish to achieve.

You updated the proposal to say:

...

a failed pattern match should error in the same way as is does for pure code, while in MonadPlus, the current behaviour could be maintained with mzero

Can you be more specific as to how that would interact with polymorphism and type inference? What does it mean to be "in MonadPlus"? How does the compiler know?

For example, what would be the static types and dynamic semantics of the following expressions:

1. \a -> do {Just x <- return (Just a); return x}

2. do {Just x <- return Nothing; return x}

3. \a -> do {Just x <- a; return x}

4. \a b -> do {(x, _) <- return (a, b); return x}

5. \a -> do {(x, _) <- return a; return x}

Tillmann

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 15/12/2010 11:39, Lennart Augustsson wrote:

Any refutable pattern match in do would force MonadFail (or MonadPlus if you prefer). So 1. (MonadFail m) => a -> m a, \ a -> return a 2. (MonadFail m) => m a, mfail "..." 3. (MonadFail m) => Maybe a -> m a, \ a -> case a of Nothing -> mfail "..."; Just x -> return x 4. (Monad m) => a -> b -> m a, \ a b -> return a 5. (Monad m) => (a, b) -> m a, \ (a, b) -> return a

As far as type inference and desugaring goes, it seems very little would have to be changed in an implementation.

Is there a need for a MonadFail, as distinct from mzero? fail always seems to be defined as error in ordinary monads, and as mzero in MonadPlus (or left at the default error).

On 15/12/2010 14:31, Lennart Augustsson wrote:

Yes, I think there should be a MonadFail distinct from MonadPlus. Some types, like IO, are not in MonadPlus, but have a special implementation of the fail method.

Personally, I think fail should just be removed, but that would break existing code. The fail method was introduced for the wrong reasons (better error messages was the excuse).

Which other monads (other than MonadPlus subclasses) define fail?

IO On Thu, Dec 16, 2010 at 6:03 PM, John Smith wrote:

On 15/12/2010 14:31, Lennart Augustsson wrote:

...

Yes, I think there should be a MonadFail distinct from MonadPlus. Some types, like IO, are not in MonadPlus, but have a special implementation of the fail method.

Personally, I think fail should just be removed, but that would break existing code. The fail method was introduced for the wrong reasons (better error messages was the excuse).

Which other monads (other than MonadPlus subclasses) define fail?

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Wed, 2010-12-15 at 13:51 +0200, John Smith wrote:

On 15/12/2010 11:39, Lennart Augustsson wrote:

...

Any refutable pattern match in do would force MonadFail (or MonadPlus if you prefer). So 1. (MonadFail m) => a -> m a, \ a -> return a 2. (MonadFail m) => m a, mfail "..." 3. (MonadFail m) => Maybe a -> m a, \ a -> case a of Nothing -> mfail "..."; Just x -> return x 4. (Monad m) => a -> b -> m a, \ a b -> return a 5. (Monad m) => (a, b) -> m a, \ (a, b) -> return a

As far as type inference and desugaring goes, it seems very little would have to be changed in an implementation.

Is there a need for a MonadFail, as distinct from mzero? fail always seems to be defined as error in ordinary monads, and as mzero in MonadPlus (or left at the default error).

Not all types can implement mplus to begin with even if they can have 'zero' type. For example technically Maybe breaks the laws while still having useful fail: (guard . even) =<< (Just 1 <|> Just 2) (guard . even) =<< Just 1 guard (even 1) guard False Nothing /= Just () Nothing <|> Just () guard False <|> guard True (guard (even 1)) <|> (guard (even 2)) ((guard . even) =<< Just 1) <|> ((guard . even) =<< Just 2) Regards

On 15 Dec 2010, at 17:48, Brent Yorgey wrote:

On Wed, Dec 15, 2010 at 06:25:30PM +0100, Maciej Piechotka wrote:

...

On Wed, 2010-12-15 at 13:51 +0200, John Smith wrote:

...

On 15/12/2010 11:39, Lennart Augustsson wrote:

...

Any refutable pattern match in do would force MonadFail (or MonadPlus if you prefer). So

[..]

...

...

...

As far as type inference and desugaring goes, it seems very little would have to be changed in an implementation.

Is there a need for a MonadFail, as distinct from mzero? fail always seems to be defined as error in ordinary monads, and as mzero in MonadPlus (or left at the default error).

Not all types can implement mplus to begin with even if they can have 'zero' type. For example technically Maybe breaks the laws while still having useful fail:

[..]

But that depends on what laws you choose for MonadPlus. See http://www.haskell.org/haskellwiki/MonadPlus .

What has any of this to do with monads? Cheers Conor