On Sun, May 2, 2010 at 12:07, Sebastian Fischer wrote: > > On May 2, 2010, at 11:10 AM, Sean Leather wrote: > > Or should I make my own class? >> >> Then, there obviously won't be any instances for existing types other than >> your own (which might be a good or bad thing). You may want to do this, if >> you don't want to require either (>>=) or (<*>), which may not be supported >> for reasonable instances of your own class. >> >> I don't really want to do this option, because it increases the >> understanding overhead needlessly, I think. Everything else that is provided >> by Applicative/Monad doesn't matter. I require only the three operations >> above and do not disallow extra operations. >> > > By not making your own class, you prohibit types that do not support <*> > (or >>=). That's fine, but an additional burden to instance writers. By not > listing extra operations in your own class you would not disallow them. You > require them by not making your own class without them. >
Understood and agreed. Having my own class would be the most flexible in what it allows and disallows. But still, your wish to reuse existing classes may be a fine reason to > impose an additional burden. There is an additional maintenance burden that I've recently become aware of, considering I haven't done a very good job of maintaining my own code. ;) To use my own class, I should reasonably provide instances for everything that I possibly can. This would include (at least) lists, Maybe, WrappedAlternative, and WrappedMonadPlus. Who knows? I may change my mind in a while. In that case, would you have any suggestions on a name for such a class or names for the methods? ;) class C f where zero :: f a one :: a -> f a append :: f a -> f a -> f a Sean
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe