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

Edward Kmett ekmett at gmail.com
Sun Nov 2 17:40:15 UTC 2014


At that point once you inline you still need to apply both args to make any
progress.

On Sun, Nov 2, 2014 at 10:51 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> 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 <ekmett at gmail.com> 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 <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
>>>
>>>
>>
>> _______________________________________________
>> 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/847d3ab7/attachment.html>


More information about the Libraries mailing list