suggestion: use lazy pattern matching for Monoid instances of tuples
Edward Kmett
ekmett at gmail.com
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.
-Edward
On Sat, Aug 17, 2013 at 4:31 PM, Petr Pudlák <petr.mvd at gmail.com> 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 haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130818/cb1359ce/attachment.htm>
More information about the Libraries
mailing list