Re: [Haskell-cafe] deepSeq vs rnf

Björn Bringert wrote:

Cale Gibbard wrote:

...

On 22/10/06, Chad Scherrer wrote:

...

Hi,

I had posted this question a while back, but I think it was in the middle of another discussion, and I never did get a reply. Do we really need both Control.Parallel.Strategies.rnf and deepSeq? Should we not always have

x `deepSeq` y == rnf x `seq` y ?

Maybe there's a distinction I'm missing, but it seems to me they're basically the same.

I agree, they are the same. The Strategies library also gives much more general operations for working with strictness and parallelisation. That library seems to need more love, I think it's a great idea, but it doesn't really get noticed all that much. The Hierarchical libraries documentation for it is a little lacking -- it doesn't even provide a reference or link to the paper, and many of the combinators, as well as the general idea of how to use it are undocumented from there. It also spuriously contains an Assoc datatype, which if I recall correctly, was an example from the paper, but doesn't really belong in the library as far as I can tell. It would also be really nice to see the list of instances for the NFData class expanded to include other datatypes in the libraries, possibly also with compiler support for deriving, since it's mostly boilerplate.

I wanted to use the Strategies library and didn't understand much of it, so I sat down and documented it. The darcs version, http://darcs.haskell.org/packages/base/Control/Parallel/Strategies.hs has my changes.

If noone objects, I could do some more clean-up, including:

- Add NFData instances for common data types, such as - Maybe - Either - Data.Map.Map - Data.Set.Set - Data.Tree.Tree - All Data.Int and Data.Word types

- Deprecate sSeq and sPar, as the code comments say that you should use demanding and sparking instead.

- Deprecate these defintions, which seem to be examples or Lolita-specific: - Assoc - fstPairFstList - force - sforce

If anyone has objections or further suggestions, let me know.

Looks good to me. I didn't really look closely at this code before enabling it, except to check that it compiled and appeared to work with a couple of the old Parallel Haskell benchmarks in nofib/par. Cheers, Simon