Proposal: Make `NFData` a fundamental/primitive type-class (by making `deepseq` a GHC-boot package)

[Herbert Valerio Riedel]

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