Discussion: Arities of <*> and *> for Monad instances

[Edward Kmett]

It seems to me that lower arity definitions could be a good thing.

They'd permit the inliner to pull the definition in in more contexts.

There is a minor sublety around strictness in your example for Maybe.

There:

(<*>) undefined = undefined

whereas with the normal definition

(<*>) undefined = const undefined

But this is one of those rare cases where I don't think anyone can build up
a viable argument for where they've ever used that particular bit of
laziness, and in fact, the extra eta expansion wrapper has probably been a
source of subtle optimization pain for a long time.

Consider me a tentative +1 unless someone can come up with a deal breaker.

-Edward

On Sun, Nov 2, 2014 at 4:29 AM, David Feuer <david.feuer at gmail.com> wrote:

>
> http://hackage.haskell.org/package/base-4.7.0.1/docs/Control-Applicative.html
> says that
>
>     The other methods have the following default definitions,
>     which may be overridden with equivalent specialized
>     implementations:
>
>     u *> v = pure (const id) <*> u <*> v
>
>
> and
>
>     If f is also a Monad, it should satisfy
>
>     ...
>     (<*>) = ap
>
>
> The (potential) trouble is that these have higher arities than is always
> natural. For example, it would seem reasonable to say
>
>     (<*>) Just f = fmap f
>     (<*>) Nothing = const Nothing
>
> and to replace the default definition of (*>) like so:
>
>     (*>) a1 = (<*>) (id <$ a1)
>
> but these are not strictly equivalent because they have arity 1 instead of
> arity 2. Would such definitions be be better in some cases? If so, should
> we weaken the rules a bit?
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141102/28468004/attachment.html>