Interesting, I hadn't thought of the SYB approach. I still need to get through those papers. Actually, I wonder if this idea would help with something else I was looking into. It seems like it might occasionally be useful to have a monad that is the identity, except that it forces evaluation as it goes. Something like: instance Monad Strict where return = Strict Strict x >>= f = rnf x `seq` f x The problem is, this won't typecheck as-is, since not everything is an instance of class NFData. I had been thinking of making a default instance, something like instance NFData a where rnf = id and then using overlapping instances. But maybe boilerplate-scrapping would make this cleaner? I'm still not sure what it can and can't do. -Chad

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.

Speaking of boilerplate and the scrapping thereof, Data.Generics could theoretically also be used to write a relatively generic rnf/deepSeq, but in my attempts, it seems to be much much slower than using a specific normal form class. Here's my code from quite a while back. As I recall, it's semantically correct, but ran about an order of magnitude slower. There might be a much better way to do it, I don't really know Data.Generics all that well.

rnf :: (Data a) => a -> () rnf x = everything (\x y -> x `seq` y) (\x -> x `seq` ()) x

deepSeq x y = rnf x `seq` y

f $!! x = rnf x `seq` f x

- Cale

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. /Björn