Proposal: Functor and friends for the wrappers in Data.Monoid
Daniel Bergey
bergey at alum.mit.edu
Tue Feb 24 14:59:48 UTC 2015
On 2015-02-24 at 14:26, Joachim Breitner <mail at joachim-breitner.de> wrote:
> Am Dienstag, den 24.02.2015, 14:00 +0000 schrieb Jake McArthur:
>> +1 do all instances of the proposal. It is so common for me to want to
>> use some polymorphic function but it not be available to me because it
>> has a constraint not satisfied by a newtype wrapper around the type I
>> want to use it with, so I have to write a bunch of boilerplate. I
>> think we should eliminate such boilerplate aggressively. I even think
>> Applicative and Monad would be useful. Just because a wrapper doesn't
>> add behavior doesn't mean we should intentionally make it incompatible
>> with so much code.
>
> your argument is valid: If I have a, say, "Num a", then I’d like to be
> able to (+) also on values of type "Sum a". Hence the instance
> Num a => Num (Sum a)
> and others of that kind (Eq, Ord, Read, Show).
>
> But your argument does not apply to the question at hand. The "Monad
> Sum" instance is not of the „the instance of the wrapped thing lifted to
> the newtype wrapper“ kind (as the wrapped thing has kind * and thus is
> not a monad). Rather, it is the „there is only one only lawful Monad
> instance for Identity, and Sum is isomorphic to Identity, so let’s use
> it here“.
Applicative is convenient for defining such instances `(+) = liftA2 (+)`
and for one-off use where the instance might be more confusing `atan2
<$> Sum 2 <*> Sum 3`.
I'm not sure what I'd do with the Monad instance except where it's
equivalent to Applicative. I still think it's useful for that, since
it's often easier to read when the intermediate values are named.
I'm +1 on all the proposed instances.
More information about the Libraries
mailing list