Proposal: Applicative => Monad: Call for consensus

[Henning Thielemann]

Dan Doel schrieb:
> 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.

Translating for me: liftA2 is essentially pair with subsequent fmap. I
already though about this and came to the conclusion, that this does not
help in my case. A zipWith3 written as
  pure f <*> storableVectorA <*> storableVectorB <*> storableVectorC
 would require a Storable instance for pairs. I provided that in
storable-tuple, but then it is not efficient to store intermediate pairs
in StorableVector.

That's why I think that an optimal solution would neither require
(Suitable a, Suitable b) => Suitable (a -> b)
nor
(Suitable a, Suitable b) => Suitable (a, b)
but would best have no such constraint at all. Using an intermediate
type does not have such an constraint, but unfortunately does not look nice.

Maybe I should switch thread topic now ...