Proposal: NF newtype

[Dan Burton]

A hand-written read makes more sense to me in this case:

read = makeNF . read
show = show . getNF

Other instances where a "new value" is created can be written similarly:

instance (Monoid m) => Monoid (NF m) where
  mempty = makeNF mempty
  mappend aNF bNF = makeNF (mappend (getNF aNF) (getNF bNF))

Whether the pattern of using NF this way is a good idea... I don't know. It
just seems nice if data of type `NF a` can be used as a drop-in replacement
for data of type `a`.

-- Dan Burton

On Wed, Apr 22, 2015 at 1:10 AM, Michael Snoyman <michael at snoyman.com>
wrote:

> Only thing I can think of is adding a bunch of `deriving`s to NF. I can
> picture people wanting to just plot an `NF` into the middle of their data
> structures and still be able to `show` it for debugging. I'm guessing a
> minimal list may be Show, Read, Eq, Ord, Typeable. Data and Generic seem
> like an interesting case, since- on the one hand- it would be nice to have
> the instances (especially the latter) for auto-deriving mechanisms, but in
> theory it can be used to break the abstraction. However, given that you're
> already giving people an escape route via the .Internal module, I don't
> think that's as big a concern.
>
> On Wed, Apr 22, 2015 at 11:04 AM Edward Z. Yang <ezyang at mit.edu> wrote:
>
>> That's what I get for guessing syntax. Fixed.
>>
>> Edward
>>
>> Excerpts from Michael Snoyman's message of 2015-04-22 08:54:32 +0100:
>> > Small request: could you bump the upper bound to allow base 4? ;)
>> >
>> > On Wed, Apr 22, 2015 at 10:50 AM Edward Z. Yang <ezyang at mit.edu> wrote:
>> >
>> > > Hello all,
>> > >
>> > > Taking the appropriate suggestion, I have created a small
>> > > package to provide this functionality:
>> > >
>> > >     https://hackage.haskell.org/package/nf
>> > >
>> > > If it migrates into deepseq, we can update this package to reexport
>> > > the appropriate modules from deepseq when it is available.
>> > >
>> > > Please let me know if there's anything (e.g. version bounds) which
>> > > I can do to make this more "enterprise" ready.
>> > >
>> > > Cheers,
>> > > Edward
>> > >
>> > > Excerpts from Edward Z. Yang's message of 2015-02-10 08:46:37 +0000:
>> > > > 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://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> > >
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150422/250efa0c/attachment.html>