[Haskell-cafe] deepSeq vs rnf

Simon Marlow simonmarhaskell at gmail.com
Tue Nov 14 05:53:46 EST 2006


Björn Bringert wrote:
> Cale Gibbard wrote:
> 
>> On 22/10/06, Chad Scherrer <chad.scherrer at gmail.com> 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


More information about the Libraries mailing list