suggestion: use lazy pattern matching for Monoid instances of tuples

Edward Kmett ekmett at
Sun Aug 18 22:44:09 CEST 2013

This change would spontaneously introduce space-leaks in currently
non-leaky code.

It'd be a debugging nightmare for existing users of the product Monoid
instance, of whom there are many, who would just see their code start to
throw away all their memory on newer GHC versions and have little or no
idea why, if they missed news of this update.

As a result I'm -1 on this proposal.

That said, some kind of package that provides a well-reasoned
Data.Tuple.Lazy data type could see use, as using it would imply consent to
those semantics.

I do not object morally to it, like Henning, merely pragmatically.


On Sat, Aug 17, 2013 at 4:31 PM, Petr Pudlák <petr.mvd at> wrote:

>  Dear haskellers,
> currently the instances are defined as
> instance (Monoid a, Monoid b) => Monoid (a,b) where
>         mempty = (mempty, mempty)
>         (a1,b1) `mappend` (a2,b2) = (a1 `mappend` a2, b1 `mappend` b2)
> However for some applications this isn't lazy enough, for example
> -- | Build two lists by folding on a pair of `Endo` monoids.test = head $ appEndo (fst $ foldMap (f &&& f) [1..]) []
>   where
>     f = Endo . (:)
> never terminates because of the unnecessary pattern matching on the
> constructor (,) forces evaluation of the whole infinite list.
> I suggest to change all Monoid instances for tuples to be like
>  instance (Monoid a, Monoid b) => Monoid (a,b) where
>          mempty = (mempty, mempty)
>          ~(a1,b1) `mappend` ~(a2,b2) = (a1 `mappend` a2, b1 `mappend` b2)--      ^^^                ^^^
> which fixes the problem.
> Best regards,
> Petr
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list