Proposal: NF newtype

[Edward Z. Yang]

Well, NF works with data that really needs a deepSeq too. The
difference seems to be (1) you can extract out the 'a' without
having deepSeq'd it and then partially evaluate it (which is not
possible with NF), and (2) it has a runtime effect, whereas NF
is purely a type discipline.

Edward

Excerpts from Edward Kmett's message of 2015-02-10 10:37:55 -0800:
> A related data type that I've made use of in the past is described here
> 
> https://www.fpcomplete.com/user/edwardk/snippets/once
> 
> This version has the benefit that it works with data that really does need
> a deepSeq, but encapsulates it in such a way that subsequent deepSeq's do
> no extra work.
> 
> -Edward
> 
> On Tue, Feb 10, 2015 at 3:46 AM, Edward Z. Yang <ezyang at mit.edu> wrote:
> 
> > I propose the following (abstract) data type, functions, and instance be
> > added to deepseq (naming amenable to bikeshedding):
> >
> >     newtype NF a = NF a -- abstract
> >     makeNF :: NFData a => a -> NF a
> >     getNF :: NF a -> a
> >     instance NFData (NF a) where
> >         rnf x = x `seq` ()
> >
> > NF is an abstract data type representing data which has been evaluated
> > to normal form; the guarantee specifically is, if NF is in whnf, then
> > it is in nf.  Crucially, when we have 'NF a', we ONLY need to seq it
> > in order to assure that it is fully evaluated.
> >
> > This guarantee is sufficient for a variety of cases where
> > normal data is necessary, e.g. when transmitting data over Channels.
> > For example, from the monad-par library 'put_' could be used in place
> > of 'put' with this type signature.
> >
> >     put_ :: IVar (NF a) -> (NF a) -> Par ()
> >
> > Cheers,
> > Edward
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> >