For me, mostly naming. Cofunctor isn't the right name for it, and comap, while short, feels wrong. Contrafunctor feels better but is also cumbersome. No problems with Comonad, though. On Thu, Dec 23, 2010 at 9:16 PM, Mario Blažević wrote:

On Thu, Dec 23, 2010 at 5:25 PM, Stephen Tetley wrote:

...

On 23 December 2010 21:43, Mario Blažević wrote:

...

Why are Cofunctor and Comonad classes not a part of the base library? [SNIP] Later on I found that this question has been raised before by Conal Elliott, nearly four years ago.

http://www.haskell.org/pipermail/libraries/2007-January/006740.html

From a somewhat "philistine" persepective, that Conal's question went unanswered says something:

"Does anyone have useful functionality to go into a Cofunctor module (beyond the class declaration)?"

Successful post-H98 additions to Base (Applicative, Arrows, ...) brought a compelling programming style with them. For Comonads, Category-extras does define some extra combinators but otherwise they have perhaps seemed uncompelling.

There are plenty of potential Cofunctor instances on Hackage, as I've pointed out. The other side of the proof of the utility of the class would be to find existing libraries that could be parameterized by an arbitrary functor: in other words, some examples in Hackage of

...

class Cofunctor c => ... instance Cofunctor c => ... f :: Cofunctor c => ...

This would be rather difficult to prove - such signatures cannot be declared today, and deciding if existing declarations could be generalized in this way would require a pretty deep analysis. The only thing I can say is "build it and they will come".

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

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ...regardless of the utility of a contravariant functor type-class, I strongly advocate for calling it Contrafunctor and not Cofunctor. I have seen numerous examples of confusion over this, particularly in other languages. On 24/12/10 12:16, Mario Blažević wrote:

On Thu, Dec 23, 2010 at 5:25 PM, Stephen Tetley mailto:stephen.tetley@gmail.com> wrote:

...

Why are Cofunctor and Comonad classes not a part of the base

On 23 December 2010 21:43, Mario Blažević mailto:mblazevic@stilo.com> wrote: library? [SNIP]

...

Later on I found that this question has been raised before by Conal Elliott, nearly four years ago.

http://www.haskell.org/pipermail/libraries/2007-January/006740.html

- From a somewhat "philistine" persepective, that Conal's question

went unanswered says something:

"Does anyone have useful functionality to go into a Cofunctor module (beyond the class declaration)?"

Successful post-H98 additions to Base (Applicative, Arrows, ...) brought a compelling programming style with them. For Comonads, Category-extras does define some extra combinators but otherwise they have perhaps seemed uncompelling.

There are plenty of potential Cofunctor instances on Hackage, as I've pointed out. The other side of the proof of the utility of the class would be to find existing libraries that could be parameterized by an arbitrary functor: in other words, some examples in Hackage of

...

class Cofunctor c => ... instance Cofunctor c => ... f :: Cofunctor c => ...

This would be rather difficult to prove - such signatures cannot be declared today, and deciding if existing declarations could be generalized in this way would require a pretty deep analysis. The only thing I can say is "build it and they will come".

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

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

- -- Tony Morris http://tmorris.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0UIJ0ACgkQmnpgrYe6r62kWgCeNwZnYLetOFevK6bpCBE/joKO 2QQAniaX4IGzAmdjEC8kdDV27upUTsBw =NP27 -----END PGP SIGNATURE-----

+1 for adding a Contrafunctor/ContraFunctor to base somewhere. But I agree completely with Tony, please call it contramap. ;) Otherwise people will wonder why comonads are not cofunctors -- a matter which can be cleared up by avoiding sloppy terminology. +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. I have been meaning to split off a 'comonads' package from category-extras for a while, in a way that avoids requiring tons of crazy machinery. I have a candidate that I just need to polish up a bit and throw on hackage -- perhaps that could serve as a straw man proposal? -Edward 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". At the moment and possibly by accident rather than explicit intention, the structures in Base (Monoid, Applicative, Monad, Arrow) add good sets of operational combinators as well as modeling structures (in Monoid's case it only adds one operational combinator but it is the basis for Foldable, the Writer Monad and more).

For Comonad, Cofunctor (Bifunctor, Semigroup...) not having the visibility of being in Base certainly means there is less motivation to discover valuable operations that use them, but should they go into Base without an initial strong operational value, instead maybe something between Base and Hackage is needed?

Certainly, Hackage isn't great for developing "Base candidates". The bike shedding on the Libraries list, whilst frustrating for a proposer, is valuable for teasing out more regular designs than single authored packages often manage, and having lots of small packages for Base-like things is a dependency burden that hinders adoption.

Best wishes

Stephen

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

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.

On Fri, Dec 24, 2010 at 5:36 AM, Edward Kmett wrote:

+1 for adding a Contrafunctor/ContraFunctor to base somewhere. But I agree completely with Tony, please call it contramap. ;) Otherwise people will wonder why comonads are not cofunctors -- a matter which can be cleared up by avoiding sloppy terminology.

+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.

I have been meaning to split off a 'comonads' package from category-extras for a while, in a way that avoids requiring tons of crazy machinery. I have a candidate that I just need to polish up a bit and throw on hackage -- perhaps that could serve as a straw man proposal?

Yes, please. The interface of Comonad is big enough to require some proper design, and an exclusive comonads package would be a good place for refining it. The same arguments can be made for ContraFunctor, though in this case the only open questions are only the naming of the module, class and its single method, and what instances to declare inside the module.

-Edward

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". At the moment and possibly by accident rather than explicit intention, the structures in Base (Monoid, Applicative, Monad, Arrow) add good sets of operational combinators as well as modeling structures (in Monoid's case it only adds one operational combinator but it is the basis for Foldable, the Writer Monad and more).

For Comonad, Cofunctor (Bifunctor, Semigroup...) not having the visibility of being in Base certainly means there is less motivation to discover valuable operations that use them, but should they go into Base without an initial strong operational value, instead maybe something between Base and Hackage is needed?

Certainly, Hackage isn't great for developing "Base candidates". The bike shedding on the Libraries list, whilst frustrating for a proposer, is valuable for teasing out more regular designs than single authored packages often manage, and having lots of small packages for Base-like things is a dependency burden that hinders adoption.

Best wishes

Stephen

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

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