Re: Proposal: NF newtype

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 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.

...

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

On Tue, Feb 10, 2015 at 6:45 AM, Michael Snoyman wrote: 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 wrote:

...

On Tue Feb 10 2015 at 1:41:48 PM Herbert Valerio Riedel 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-T...

...

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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries