Today a student has shown me a program that consists of a large 'do' block for the list monad. The program looks like do x1 <- [0..3] x2 <- [0..2] ... x600 <- [0..5] guard (x1+x2+2*x3 >= 0) ... return (x1,x2,....,x600) It was actually generated by another program. The results were: GHC-6.4 was not able to compile that program at all, because it stopped because of memory exhaustion. GHC-6.8.2 finished compilation after two minutes but the program aborted quickly because of a corrupt thunk identifier. GHC-6.10 not yet tested. Hugs-2006 executed the program without complaining and showed the first result after a few seconds: (0,0,0,0,0,...,0). Eventually the program must run on a Linux cluster with a not up-to-date Linux kernel, that is, I suspect newer GHC versions cannot be used due to the 'timer_create' problem. (At least, the 'cabal' executable that I generated with a GHC-6.8.2 had this problem when running on the cluster which reminded me on the problems with GHC-6.8 itself running on older Linux kernels.) Since the list monad sorts the variable values in lexicographic order which is inappropriate for the considered problem, I recommended the use of control-monad-omega. Luke, I hope this monad can cope with 600 variables. :-)