Church uses eager evaluation, where Haskell uses lazy evaluation by default. Church does this for two reasons. Firstly, Church works by translating Church source code into Java source to be compiled to run on a standard Java VM. As Java's evaluation is eager, the source-to-source translation is made more direct by adopting the conventions of the host platform. Secondly, at a minimum, lazy values have storage requirements that have to provide space for one extra value: the not-evaluated state. So a lazy Boolean has three states: true, false and not-evaluated which requires two bits of storage. For numerical primitives types, like int and double, there is a significant performance penalty incurred by representing their lazy numerical values: fundamentally because the 2^32 + 1 or 2^64 +1 states don't fit into the appropriate machine word. Use of the heap for numerical computations typically causes at least an order of magnitude in performance loss and far greater losses are possible when thunks cause memory leaks. GHC is able to mitigate, and in many cases completely eradicate, these problems with a combination of strictness analysis, the strictness annotation, !, and the, $!, compiler directive.