On Fri, Dec 24, 2010 at 7:43 AM, Maciej Piechotka <uzytkown...@gmail.com>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 <stephen.tet...@gmail.com>wrote: > On 24 December 2010 02:16, Mario Blažević <mblaze...@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". 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
