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