On Wednesday 24 August 2011, 07:32:45, wren ng thornton wrote:

On 8/23/11 9:23 AM, Gregory Collins wrote:

...

On Tue, Aug 23, 2011 at 1:39 PM, Herbert Valerio Riedel wrote:

...

Proposal: ~~~~~~~~~

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

+1.

...

I'm strongly in favour of this also. IIRC Ian was the one who objected most strenuously last time. What sayest thou, Ian?

I'm curious about that too.

I seem to recall that Ian is on vacation, so your curiosity would have to wait a bit. Unless good reasons against surface, I support this proposal too.

On 24/08/2011 22:38, Ian Lynagh wrote:

On Tue, Aug 23, 2011 at 03:23:04PM +0200, Gregory Collins wrote:

...

On Tue, Aug 23, 2011 at 1:39 PM, Herbert Valerio Riedel wrote:

...

Proposal: ~~~~~~~~~

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

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

I'm strongly in favour of this also. IIRC Ian was the one who objected most strenuously last time. What sayest thou, Ian?

In general, my opinion is still that we should be trying to make base smaller, not larger. Some stats:

Are you also opposed to making deepseq a GHC-boot package? Any subsequent proposal to merge it into base could be countered at that point with an alternative proposal to move other things out of base instead and have them depend on deepseq. Ganesh

On Wed, Aug 24, 2011 at 10:53:07PM +0100, Ganesh Sittampalam wrote:

Are you also opposed to making deepseq a GHC-boot package?

Not if there's a good reason for it. Perhaps allowing a better Map instance is one. Thanks Ian

On Wed, 2011-08-24 at 22:38 +0100, Ian Lynagh wrote:

...

...

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

I'm strongly in favour of this also. IIRC Ian was the one who objected most strenuously last time. What sayest thou, Ian?

In general, my opinion is still that we should be trying to make base smaller, not larger.

That's fine too -- although merging `deepseq` w/ `base` is beyond this proposal (I mentioned it for the case `NFData` was about to make its way into a future Haskell20xx (Library) Report). But what's about the actual proposal at hand? +1 or -1? :-) However, out of curiosity and generally speaking: What should be part of `base` anyway? The current descriptions says | This package contains the Prelude and its support libraries, and a | large collection of useful libraries ranging from data structures to | parsing combinators and debugging utilities. -- hvr

+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

On Thu, Aug 25, 2011 at 9:12 AM, Simon Peyton-Jones wrote:

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.

No. Lets just reverse the containers <-> deepseq dependency and make deepseq a bootlib. Johan

On 25/08/2011 08:12, 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?

The proposal is to make deepseq a boot package, not to move anything into base.

In principle, you can do this:

* Implement deepseq

* 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

That's what we have right now, the problem is that deepseq can't define a good instance for NFData Map, because it can't see enough of the internals of Map.

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.

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.

Exactly, that's the proposal! (+1 from me, BTW) Cheers, Simon

Simon Marlow writes:

That's what we have right now, the problem is that deepseq can't define a good instance for NFData Map, because it can't see enough of the internals of Map.

Couldn't the strict foldl do it?