Proposal: NF newtype

[Carter Schonwald]

i dont think it would be unsafe relative to unsafe haskell, merely unsafe
wrt the semantical guarantees of the NF type

On Tue, Feb 10, 2015 at 12:08 PM, David Feuer <david.feuer at gmail.com> wrote:

> +1, generally. Two thoughts:
>
> 1. There are, as far as I know, two reasonable senses of NF that one
> might care about. The weak sense is a guarantee that the structure has
> no accessible bottoms within it that would be reached if the structure
> were evaluated to normal form, along with a guarantee that it is
> impossible to use it to force lazy IO. A stronger sense offers some
> kind of performance guarantee, which seems much trickier to specify.
> Whether something is *actually* in normal form is not observable
> without using something like ticky-ticky profiling, so I don't think
> we're allowed to care about that. Since I support the idea of
> unsafeMakeNF, and perhaps other special NF-creation functions, I think
> it's important to be clear about just what it's supposed to mean.
>
> 2. I think it makes a lot of sense to put unsafeMakeNF into a separate
> Unchecked module, presumably declared unsafe for Safe Haskell.
>
> On Tue, Feb 10, 2015 at 6:45 AM, Michael Snoyman <michael at snoyman.com>
> wrote:
> > Forgot to mention: I'm +1 on the proposal in general, though it would be
> > nice if these types/functions were available from a compatibility
> library as
> > well, since deepseq is now bundled with GHC and therefore difficult to
> > upgrade on its own.
> >
> > On Tue Feb 10 2015 at 1:43:52 PM Michael Snoyman <michael at snoyman.com>
> > wrote:
> >>
> >> On Tue Feb 10 2015 at 1:41:48 PM Herbert Valerio Riedel <hvr at gnu.org>
> >> wrote:
> >>>
> >>> On 2015-02-10 at 09:46:37 +0100, Edward Z. Yang 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` ()
> >>>
> >>> I generally like it, so count me as +1
> >>>
> >>> bikeshed-wondering though, why did you make it abstract w/ separate
> >>> construct/deconstructors?
> >>>
> >>>
> >>
> >> If the real constructor was available, then someone would be free to
> write
> >> something like:
> >>
> >>     let foo = NF $ 1 : undefined
> >>
> >> which would break the guarantees that this type is trying to provide.
> >>
> >>>
> >>> as a related concept (and hoping not to derail the discussion too
> much),
> >>> I had attempted some time ago to implement TH predicates  that could
> >>> infer if WHNF=NF holds:
> >>>
> >>>
> >>>
> http://hackage.haskell.org/package/deepseq-th-0.1.0.4/docs/Control-DeepSeq-TH.html#v:typeWhnfIsNf
> >>>
> >>> and back then I was wondering, if GHC couldn't help us out here (maybe
> >>> by providing an implicit NF=WHNF class-instance -- and btw, I recently
> >>> found out, Haskell 1.4 had an implicit 'Eval'-class declaring
> >>> `seq`-ability)
> >>>
> >>> I'm not sure though if WHNF=NF can always be decided...
> >>>
> >>>
> >>> Cheers,
> >>>   hvr
> >>> _______________________________________________
> >>> Libraries mailing list
> >>> Libraries at haskell.org
> >>> http://www.haskell.org/mailman/listinfo/libraries
> >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> >
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150210/db1985ee/attachment.html>