On Fri, 2009-01-23 at 13:39 -0800, George Pollard wrote: > On Fri, 2009-01-23 at 21:30 +0000, Joachim Breitner wrote: > > Hi, > > > > Am Freitag, den 23.01.2009, 21:50 +0100 schrieb Henning Thielemann: > > > However our recent Monoid discussion made me think about mapM_, > > > sequence_, and friends. I think they could be useful for many monads if > > > > they would have the type: > > > mapM_ :: (Monoid b) => (a -> m b) -> [a] -> m b > > > I expect that the Monoid instance of () would yield the same > efficiency > > > as todays mapM_ > > > > will it? This is based on a naive, not well-founded understanding of > > haskell evaluation, but looking at > > > instance Monoid () where > > > mempty = () > > > _ `mappend` _ = () > > > mconcat _ = () > > I’d assume that evaluating > > > mapM_ (putStrLn) lotsOfLargeStrings > > with your proposed mapM_ will leave a thunk equivalent to > > > () `mappend` () `mappend` () `mappend`... > > in memory until the mapM_ has completely finished, where each () is > > actually an unevalutated thunk that still has a reference to one of the > > elements in the lotsOfLargeStrings list. > > Perhaps this is why the Monoid instance for () in GHC's source has the > comment "should this be strict?" :)
It's easy to calculate the answer. mempty `mappend` undefined = undefined (left identity monoid law) The above definition doesn't meet this, similarly for the right identity monoid law. That only leaves one definition, () `mappend` () = () which does indeed satisfy the monoid laws. So the answer to the question is "Yes." Another example of making things as lazy as possible going astray. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
