[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