Summary: 2 programs failed to compile due to type errors (anna, gg). One program did 19% more allocation, a few other programs increased allocation very slightly (<2%). pic +0.28% +19.27% 0.02 Thanks, that was interesting. A follow-up question: pic has a space bug. How long will it take you to find and fix it? And how come speed improved slightly in many cases--that seems counter- intuitive. Let me make clear that what concerns me is not the impact of the M-R on space and time performance on average. What concerns me is the difficulty of debugging performance problems. Even if we Haskell programmers usually consider correctness first and performance later, when we want to actually use our beautiful code, we need to find and fix at least the worst performance problems. At that point, I'm reading the code and trying to understand--with the help of profiling tools--why it performs the way it does. I need the performance behaviour of the code to be *obvious*. When I pull out a common sub-expression into a let-binding, I want to *know* that it will be evaluated at most once. When I see a collection of variable bindings, likewise, I want to *know* that they are computed once only. When I see a seq on such a variable, I want to *know* that any pointers in its unevaluated form are thereby dropped. When I introduce or remove overloading in a function definition, I want to *know* that I have not thereby changed the sharing properties of a variable binding somewhere else, potentially introducing a space or time leak. I want to know these things by looking at the code in front of me, not by running the compiler with the right flags and reading its warning messages. Unexpected behaviour at this point is a trap, that can lead to many wasted hours as one reads the same code again and again, assuming it behaves as expected, only to eventually convince oneself, by long examination of profiles, that it cannot be doing so. If the unexpected behaviour is rare, that only means that when it *does* happen, it will take all the longer to find and fix. I find languages with such traps intensely frustrating to work with. If I can't even tell, *by reading it*, what my code means, then what hope have I got? There are plenty who will argue, quite reasonably, that lazy evaluation in itself makes understanding performance behaviour unreasonably difficult; that strict languages should be preferred because the space and time behaviour is much more obvious. I don't agree, because I find the software engineering benefits of lazy evaluation to be so large, that it's worth the cost in making performance reasoning more difficult --but I accept there is a trade-off there. I don't see benefits on anything like the same scale from dropping the M-R. Today's M-R has the merit that it at least makes it evident, in the code, where sharing may be lost. It's often a minor irritant, occasionally a bit more than minor. Were it to be removed with no replacement, then the irritation would go away, and the signs are that most of the time, performance would not change much. But occasionally--just occasionally--there would be a space or time bug caused by loss of sharing *somewhere* in a large body of code, and searching for it, we would descend into nightmare. I'll put up with the irritation any day, to be sure of being spared the nightmare. John