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@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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries