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

[Mario Blažević]

On Fri, Dec 24, 2010 at 5:36 AM, Edward Kmett <ekmett at gmail.com> 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 <stephen.tetley at gmail.com>wrote:
>
>> On 24 December 2010 02:16, Mario Blažević <mblazevic at stilo.com> 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20101224/def41d86/attachment.htm>