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

why not move them totally to the right hand side then? eg (*>) = \ u v -> pure (const id) <*> u <*> v On Sun, Nov 2, 2014 at 10:00 AM, Edward Kmett wrote:

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 wrote:

...

http://hackage.haskell.org/package/base-4.7.0.1/docs/Control-Applicative.htm... 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries