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