
Hello, Mr. McBride and mr. Paterson define in their Applicative paper:
data Except e a = OK a | Failed e instance Monoid e => Applicative (Except e) where ...
Sometimes I'd still like to use >>= on Excepts but this "feels" wrong somehow, because it doesn't use monoids nicely like the Applicative instance does. Are there any good reasons such a Monad instance shouldn't be defined? Does it violate any laws, for example? Thanks, Martijn.

Martijn van Steenbergen wrote:
Hello,
Mr. McBride and mr. Paterson define in their Applicative paper:
data Except e a = OK a | Failed e instance Monoid e => Applicative (Except e) where ...
Sometimes I'd still like to use >>= on Excepts but this "feels" wrong somehow, because it doesn't use monoids nicely like the Applicative instance does. Are there any good reasons such a Monad instance shouldn't be defined? Does it violate any laws, for example?
Thanks,
Martijn. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
I'm sure you could, but then ap /= (<*>). This seems related to a question that I once asked http://www.haskell.org/pipermail/haskell-cafe/2009-January/054139.html -- Tony Morris http://tmorris.net/

Martijn van Steenbergen wrote:
Hello,
Mr. McBride and mr. Paterson define in their Applicative paper:
data Except e a = OK a | Failed e instance Monoid e => Applicative (Except e) where ...
Sometimes I'd still like to use >>= on Excepts but this "feels" wrong somehow, because it doesn't use monoids nicely like the Applicative instance does. Are there any good reasons such a Monad instance shouldn't be defined? Does it violate any laws, for example? Isn't the Except type just Either by another name? OK = Right, Failed = Left. Therefore the monad is just the same as the Either monad, and is useful as an error monad:
instance Monad (Except e) where (OK x) >>= f = f x Failed e >>= _ = Failed e return = OK This obeys all the monad laws. Thanks, Neil.

Yes, however, ap is not equal to (<*>) for the given Applicative. I don't believe such a monad is possible. Neil Brown wrote:
Martijn van Steenbergen wrote:
Hello,
Mr. McBride and mr. Paterson define in their Applicative paper:
data Except e a = OK a | Failed e instance Monoid e => Applicative (Except e) where ...
Sometimes I'd still like to use >>= on Excepts but this "feels" wrong somehow, because it doesn't use monoids nicely like the Applicative instance does. Are there any good reasons such a Monad instance shouldn't be defined? Does it violate any laws, for example? Isn't the Except type just Either by another name? OK = Right, Failed = Left. Therefore the monad is just the same as the Either monad, and is useful as an error monad:
instance Monad (Except e) where (OK x) >>= f = f x Failed e >>= _ = Failed e return = OK
This obeys all the monad laws.
Thanks,
Neil. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Tony Morris http://tmorris.net/

Hi, Martijn van Steenbergen wrote:
Mr. McBride and mr. Paterson define in their Applicative paper:
data Except e a = OK a | Failed e instance Monoid e => Applicative (Except e) where ...
Sometimes I'd still like to use >>= on Excepts but this "feels" wrong somehow, because it doesn't use monoids nicely like the Applicative instance does. Are there any good reasons such a Monad instance shouldn't be defined? Does it violate any laws, for example?
The problem is that one would like to define Failed e1 >> Failed e2 = Failed (e1 `mappend` e2) but then p >> q is no longer the same as p >>= const q which could be confusing. Tillmann
participants (4)
-
Martijn van Steenbergen
-
Neil Brown
-
Tillmann Rendel
-
Tony Morris