Proposal: Make `NFData` a fundamental/primitive type-class (by making `deepseq` a GHC-boot package)
ekmett at gmail.com
Tue Aug 23 15:49:35 CEST 2011
Sent from my iPhone
On Aug 23, 2011, at 7:39 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:
> 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 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 and
> efficiency from being defined locally by having access to the
> internal representations
> 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) 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.
> : http://hackage.haskell.org/trac/ghc/ticket/4868
> : http://www.haskell.org/pipermail/libraries/2010-December/015427.html
> : http://www.haskell.org/pipermail/libraries/2010-December/015428.html
> : http://www.haskell.org/pipermail/libraries/2011-January/015488.html
> -- hvr
> Libraries mailing list
> Libraries at haskell.org
More information about the Libraries