Hello Simon, On Thu, 2011-08-25 at 07:12 +0000, Simon Peyton-Jones wrote:
| 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?
I regret not having made it clearer that merging with `base` is beyond the current proposal (and mostly under the assumption that it reaches equal footing with type-classes such as Eq w.r.t. to standardisation) Also I'm a bit mislead by `base`'s description including "large collection of useful libraries", from which I assumed that it wouldn't be such a big deal to include a lightweight and useful type-class such as `NFData` in `base` anyway... :-)
In principle, you can do this:
* Implement deepseq
I'm not sure I understand what you mean by "implement deepseq" exactly... so... what do you mean by it?
* 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
Are there "abstract" GHC types whose internal representation isn't visible outside the defining modules (and which would be sensible to have access to for efficient deepseq/rnf implementations)?
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.
That's a slight understatement... it's not only `containers` but you'd get also 'array' and every other GHC-boot package (e.g. `time` and `bytestring`) that `deepseq` decides to define NFData instances for depended upon... And to be honest, the other issue of not having access to the internal representation of the data-structures is important too as it requires NFData instances to use the possibly suboptimal exported API, leading to potentially inefficient NFData instances (which is a bit counterproductive IMHO, as NFData is mostly used for benchmarking and parallelism, where I assume efficiency of the NFData operation would be desirable)
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.
...may I count this as a +1 for the core proposal (i.e. just the containers+array <-> deepseq dependancy reversal + inclusion as GHC-boot packge)? :-)
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.
Indeed, that's not a reason to merge `deepseq` (= NFData type-class & instances for base-types) into `base` at this point. -- hvr