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
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