Maybe I misinterpret the Haskell Report but I thought it does not even demand call-by-need evaluation (it only speaks of non-strict semantics). So why have a special rule in the language definition to support something cbn-ish for this particular case? As long as the Report does not specify any execution model the MR looks rather arbitrary to me. Well, the Haskell Report may not require call-by-need semantics, but it permits it at least. Without the MR that would not be the case: some programs would *require* call-by-name. Actually I would prefer the report to be much more explicit about both sharing and evaluation order, to enable compiler-independent reasoning about time and space behaviour. As it stands, compilers do in fact implement call-by-need, and so one can in practice reason fairly safely about time behaviour, but they vary in the choice of evaluation order, which makes space leaks come and go on different compilers. In any case, I don't buy the argument that because reasoning about costs is already problematic in Haskell, it doesn't matter if we make it even harder...! > Breaking the monomorphism restriction in ANY case makes both > space and time cost of evaluation unpredictable, and brittle > when program changes elsewhere introduce or remove an implicit > parameter. It isn't good enough to say `the chances are' that > a program has, for example, linear time and constant space > complexity: the programmer should be able to convince himself > of such properties. Why isn't it good enough if the compilers give warnings then? The Report could even require it. To me it seems overly restrictive to rule out perfectly correct programs for the sole reason of potentially surprising space/time behaviour. After all it is not forbidden to write Haskell programs with obscure space leaks. I have no faith in compiler warnings. For one thing, they're irritating. For another, you don't see them when it matters -- when you *read* the code. I'd far rather explicitly distinguish call-by-name and call-by-value in the source code (and made a suggestion along these lines some time ago), so that the semantics is visible to all. Of course, we can't forbid the programmer to write inefficient programs. But we can make gross inefficiencies easier or harder to find. Haskell just can't be used in practice unless one tracks down and fixes space leaks. I don't want to be debugging "time leaks" caused by unexpected call-by-name as well! -- Andreas Rossberg, rossberg@ps.uni-sb.de John Hughes