Re: [Haskell-cafe] (Co/Contra)Functor and Comonad

I remember seeing this very discussion about pointed being disjoint from functor just recently on one of the various haskell mailing lists. But as for my opinion on it, because there's no real way of specifying any laws for pointed without functor. With functor and pointed, you can say that you expect fmap f . point == point . f, but point on its own gives you nothing to latch onto for behavior expectations. On Fri, Dec 24, 2010 at 11:08 AM, Mario Blažević wrote:

On Fri, Dec 24, 2010 at 7:43 AM, Maciej Piechotka wrote:

...

On Fri, 2010-12-24 at 05:36 -0500, Edward Kmett wrote:

...

+1 for adding Comonads. As an aside, since Haskell doesn't have (nor could it have) coexponential objects, there is no 'missing' Coapplicative concept that goes with it, so there can be no objection on the grounds of lack of symmetry even if the Functor => Applicative => Monad proposal goes through.

There is still potentially useful Copointed/CoPointed:

class [Functor a =>] CoPointed a where copoint :: f a -> a

Why should Copointed, or Pointed for that matter, be a subclass of Functor? I don't see the point of arranging all possible classes into a single complete hierarchy. These single-method classes can stand on their own. Once you have them, it's easy to declare

...

class (Functor f, Pointed f) => Applicative f

and also

...

class (Foldable f, Pointed f) => Sequence f

or whatever.

On Fri, Dec 24, 2010 at 4:51 AM, Stephen Tetley wrote:

...

On 24 December 2010 02:16, Mario Blažević wrote:

...

To turn the proof obligation around, what could possibly be the downside of adding a puny Cofunctor class to the base library?

Hi Mario

For the record I'm personally neutral on Cofunctor and on balance would like to see Comonad added to Base.

My reservation is really at the "meta-level" - I suspect there are a lot of candidates for adding to Base if you want to Base to be systematic about "modeling structures".

There is a limited number of methods with up to N unconstrained arguments, combinatorics takes care of that.

class Foo (x :: *) where method1 :: x -- default, mempty, minBound, maxBound method2 :: x -> x -- succ, pred, negate method3 :: x -> x -> x -- mappend method4 :: (x -> x) -> x -- fix

class Cons (c :: * -> *) where method1 :: x -> c x -- return, pure method2 :: c x -> x -- extract method3 :: c (c x) -> c x -- join method4 :: c x -> c (c x) -- duplicate method5 :: c (c x) -> x method6 :: x -> c (c x) method7 :: x -> c x -> c x method8 :: c x -> c x -> x method9 :: (x -> x) -> c x -> c x method10 :: (x -> y) -> c x -> c y -- fmap method11 :: (x -> y) -> c y -> c x -- contramap method12 :: x -> c y -> c y method13 :: x -> c y -> c x method14 :: c x -> c y -> x method15 :: c x -> (x -> c x) -> c x method16 :: c x -> (x -> c y) -> c y -- >>= method17 :: c x -> (c x -> x) -> c x method18 :: c x -> (c x -> y) -> c y -- extend

I may have left something out, but all types above should be inhabited. I have omitted methods on constructors that can be defined on a plain type, such as mplus :: m a -> m a -> m a, which is a restriction of the type of mappend.

If one were to explore the design space systematically with no backward compatibility baggage, the best approach might be:

- declare each method in a class of its own, with no laws whatsoever, - never declare two methods in a same class, - combine the primitive classes into bigger classes, - restrict the bigger classes with laws.

The Pointed and Copointed classes above are two examples.

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