Am Sonntag, 23. Januar 2005 15:58 schrieb Jorge Adriano Aires:
I'm not arguing that definition would be "wrong". It is a monoid. This is the instance for ():
instance MonadPlus() where mzero = () mplus a b = ()
Maybe I'm stupid, but: class Monad m => MonadPlus m where mzero :: m a mplus :: m a -> m a -> m a How does () fit into this, () isn't of kind * -> *, as far as I know () Int is meaningless -- just checked, gives Kind Error.
And this would be "correct" too:
instance MonadPlus Maybe where mzero = Nothing mplus a b = Nothing
instance MonadPlus [] where mzero = [] mplus a b = []
Both aren't correct, since mzero `mplus` x == x doesn't hold (they're syntactically correct, though).
Which are not really useful. I'm claiming that the fact that Maybe is a trivial Monoid doesn't mean we should "dumb" down other instances, like the one on lists. The usual definition of Monoid on lists is [] as identity and ++ as the monoid operation. That is how it's defined in class monoid, and I expect this relation to hold:
instance MonadPlus m => Monoid (m a) where mempty = mzero mappend = mplus
Then, I'd say you're not thinking of monadic sums, but of catching errors, and the appropriate place for that is the class MonadError.
I am thinking about how some monads are summed - like Maybe and the Parser monad.
But, this is not how monadic parsers are summed. Just look into the instace of MonadError for Text.ParserCombinators.ReadP.P. Again it would be the case for parsers that would return just one possible parsing, but not for parsers that return [(a,String)].
J.A.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Daniel