Proposal: Make `NFData` a fundamental/primitive type-class (by making `deepseq` a GHC-boot package)
Herbert Valerio Riedel
hvr at gnu.org
Thu Aug 25 09:53:25 CEST 2011
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
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
> 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
...may I count this as a +1 for the core proposal (i.e. just the
containers+array <-> deepseq dependancy reversal + inclusion as GHC-boot
> 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.
More information about the Libraries