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

Ross Paterson wrote:

On Mon, Nov 13, 2006 at 02:47:20PM +0100, Björn Bringert wrote:

...

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.

Perhaps it would make sense to move all the NFData material to a new module called, say, Control.NormalForm, and maybe add a deepSeq function there. Control.Parallel.Strategies is a somewhat surprising place to find normal form functions, and most of the people who are using them aren't thinking about parallelism.

Agreed. [ Bikeshed time: Control.Evaluation.Strategies anyone? ] Regards, Malcolm

On Fri, Nov 24, 2006 at 02:53:45PM +0000, Malcolm Wallace wrote:

Ross Paterson wrote:

...

Perhaps it would make sense to move all the NFData material to a new module called, say, Control.NormalForm, and maybe add a deepSeq function there. Control.Parallel.Strategies is a somewhat surprising place to find normal form functions, and most of the people who are using them aren't thinking about parallelism.

Agreed. [ Bikeshed time: Control.Evaluation.Strategies anyone? ]

The suggestion is a module containing just class NFData, instances for Prelude types, and perhaps deepSeq :: NFData a => a -> b -> b deepSeq x y = rnf x `seq` y Shouldn't it have something like NF in the name?

Ross Paterson wrote:

...

...

Perhaps it would make sense to move all the NFData material to a new module called, say, Control.NormalForm,

Agreed. [ Bikeshed time: Control.Evaluation.Strategies anyone? ]

The suggestion is a module containing just class NFData, instances for Prelude types, and perhaps

deepSeq :: NFData a => a -> b -> b deepSeq x y = rnf x `seq` y

Shouldn't it have something like NF in the name?

Well, "NormalForm" perhaps, cryptic abbreviations like NF, no. But that aside, I hadn't realised you were proposing to move so little. Would it not be useful to have a lot more of the evaluation strategy stuff widely available, even to sequential programs? Regards, Malcolm