Proposal: Applicative => Monad: Call for consensus

[Dan Doel]

On Thursday 20 January 2011 5:23:56 pm Henning Thielemann wrote:
> Translating for me: liftA2 is essentially pair with subsequent fmap.

Yes. And I didn't mention it, but there's a similar restricted functor 
underlying the restricted applicative, which is a functor from a subcategory 
of Hask to Hask. So:

  rfmap :: (Suitable a, Suitable b) => (a -> b) -> f a -> f b

In the normal applicative case:

  pure  x = fmap (const x) unit
  f <*> x = fmap eval (pair (f, x))
    where eval = uncurry ($)

But the latter doesn't make sense if exponentials don't exist.

> 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.

I can believe it isn't efficient. But it's possible. An implementation more 
like vector (for instance) would obviously work out better, because:

  unit = UnitVector
  pair (l, r) = PairVector l r

instead of building a new vector and copying all the elements. Anyhow, my 
mails were more concerned with whether or not these things are 'unprincipled 
hacks,' not whether they're practically useful.

-- Dan