On Tue, Feb 05, 2008 at 10:51:29AM +0000, Simon Peyton-Jones wrote: > > hunk ./compiler/utils/UniqFM.lhs 701 > - | j ==# i = mkLeafUFM j (f old new) > + | j ==# i = mkLeafUFM j $! f old new > > This gives UniqFM a very odd behaviour: it becomes strict in the *range* > (element type) when, but only when, you insert a second element with the same > key as an existing one.
Ah, true, it is rather inconsistent. The problem, IIRC, was that we were doing lots of plusUFM's, so f was essentially const, but we were leaking a lot of space keeping the unused value around. So it's f, not old/new, that I really wanted to evaluate. I did at some point try making UniqFM strict, but that caused memory usage to head off to infinity, possibly due to this: > I could just about imagine that making UniqFM *always* strict in its elements > might make sense. At least it would be consistent. The one place I know > we'd have to fix (by adding an extra Lift) is in the forkM in > LoadIface.loadDecl. But otherwise it'd probably be ok. I'll take a deeper look at making it strict. Thanks Ian _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
