| Make `NFData` a fundamental/primitive type-class | (by making `deepseq` a GHC-boot package) The goals are good, but I don't follow the proposed design. In particular, why does the deepseq package need to be in base? In principle, you can do this: * Implement deepseq * Add instances for GHC types and container types; these instances wouldn't be orphans because they'd be in the module defining the NFData class The main objection seems to be this: * deepseq would thereby depend on 'containers' (say), whereas a random customer of deepseq might find that odd. And it might increase the size of his binaries. The solution to that is to make containers depend on deepseq. That would induce the inverse dependency: every user of containers would get deepseq willy-nilly. Perhaps that is less bad. And it would make 'deepseq' into a GHC boot package, which is probably fine. But that *isn't* a reason to merge deepseq into the already too-big base package, is it? And that is the root of Ian's objection. Simon