Deepseq the result of typechecking a module to avoid a space leak.

[brianhuffman]

Previously, unevaluated apSubst thunks were retaining copies of
a very large Subst value.

Fixes #888.

[brianhuffman]

I'm looking for some feedback here: I'm not sure that tcModule is the nicest place to put the deepseq call, as the motivation for it depends on knowing that runInferM uses apSubst internally. Maybe it would be better, and make the code more understandable and maintainable, to add deepseq calls to runInferM instead? Are there any cases where we wouldn't want to use deepseq on the result of runInferM? Or maybe deepseq is too blunt of an instrument; should we just make apSubst more strict instead?

[robdockins]

I usually prefer to add strictness annotations to datatypes rather than using deepseq. I think it makes the programmer intent more clear, and it is less fragile against future code changes than manually inserting seq or deepseq. Deepseq also requires and additional pass over datatypes to force them, whereas constructing them more strictly in the first place avoids an extra pass. Finally, I also think it helps the compiler produce better code by propagating strictness information throughout the program; you can avoid building thunks in the first place, and save some allocations, etc.

[brianhuffman]

I would probably prefer that too, but the typed-AST data types use recursion through Maybe, list, Map, etc; those would have to be replaced with strict variants.

I think that adding strictness to the definition of apSubst would be a good design; it already has to do a pass over the whole AST, so making it more strict wouldn't add any additional work. Also, it applies strictness in exactly the right places, since you can ignore those subterms that don't contain variables that need to be substituted.

[brianhuffman]

Closing in favor of #895.