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