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

+1 On Tue, Aug 23, 2011 at 3:49 PM, Edward Kmett wrote:

+1

Sent from my iPhone

On Aug 23, 2011, at 7:39 AM, Herbert Valerio Riedel wrote:

...

Proposal: ~~~~~~~~~

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

Discussion deadline: 2 weeks.

Note: This is a reboot of a previous unresolved proposal[1] by Johan Tibell with a slightly different emphasis.

Current Issues: ~~~~~~~~~~~~~~~

- The `deepseq` package should not depend on `containers` and `array`   (ideally `deepseq` would be merged with `base` and   `containers`/`array` would define their own `NFData` instances)

- Not all data types defined by "core libraries" have `NFData` instances   defined (e.g. `time` and `bytestring`). The lack of such "standard"   instances causes users of `deepseq` to define local orphan instances

- GHC boot packages can't depend on `deepseq` as it is not a GHC-boot   package yet, and thus orphan instances are required for those   packages -- which would benefit in terms of maintainability[4] and   efficiency[3] from being defined locally by having access to the   internal representations

Rationale: ~~~~~~~~~~

The principal idea this proposal is based upon is that the `NFData` type-class is similarly universal/basic/fundamental as the `Ord`, `Show`, or `Eq` type-classes are -- it might be even desirable to make `NFData` part of a future Haskell Prelude at some point and maybe even allow automatic instance derivation.

Building on this idea that `NFData` is a "primitive" type-class, the next best thing that can be done relatively easy and short-term as a transitional step is to

1) make `deepseq` a GHC-boot package[2],

2) remove `deepseq`'s dependancy on `array` and `containers`,

3) move the affected instance definitions to the `array` and    `containers` packages respectively, and

4) satisfy the PVP by incrementing package versions where necessary.

This should provide a path of least resistance, as no packages depending on `deepseq` would have to be adapted except for maybe PVP-related version constraint widening.

Moreover, this would pave the way for a future proposal to merge the `deepseq` into `base` at some later point.

References: ~~~~~~~~~~~

[1]: http://hackage.haskell.org/trac/ghc/ticket/4868 [2]: http://www.haskell.org/pipermail/libraries/2010-December/015427.html [3]: http://www.haskell.org/pipermail/libraries/2010-December/015428.html [4]: http://www.haskell.org/pipermail/libraries/2011-January/015488.html

-- hvr

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Nicolas Pouillard http://nicolaspouillard.fr