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

[Nicolas Pouillard]

+1

On Tue, Aug 23, 2011 at 3:49 PM, Edward Kmett <ekmett at gmail.com> wrote:
> +1
>
> Sent from my iPhone
>
> On Aug 23, 2011, at 7:39 AM, Herbert Valerio Riedel <hvr at gnu.org> 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>



-- 
Nicolas Pouillard
http://nicolaspouillard.fr