Proposal: Applicative => Monad: Call for consensus

Dan Doel dan.doel at gmail.com
Thu Jan 20 22:15:48 CET 2011


On Thursday 20 January 2011 3:26:53 pm Henning Thielemann wrote:
> I could define an RApplicative class only if I introduced an auxiliary
> type, in the example a stream-fusion:Stream. Then I could define a
> ZipList instance for StorableVector by converting each StorableVector to
> Stream and the zipped resulting Stream back to StorableVector.

Relating to my other mail, applicatives are already sort of equipped to be 
restricted, because their category theoretic analogues are lax monoidal 
functors. However, you need to look at their first-order interface:

  unit :: f ()
  pair :: (f a, f b) -> f (a, b)

The Applicative class takes advantage of the existence of exponential objects 
to provide a nicer interface to program with, but the above is the closer to 
the category theory. So, we can probably define a restricted applicative like 
so:

  let Suitable identify a monoidal subcategory of Hask, with Suitable () and
    (Suitable a, Suitable b) => Suitable (a, b)
  A restricted applicative is a lax monoidal functor from the subcategory to
    Hask, so:

    unit :: f ()
    pair :: (Suitable a, Suitable b) => (f a, f b) -> f (a, b)

Satisfying some coherence conditions. In general, the subcategory needn't have 
(all) exponential objects, so we cannot provide the Applicative interface. The 
only problem with this in Haskell might be enforcing the conditions on 
Suitable.

-- Dan



More information about the Libraries mailing list