Proposal: NF newtype

[David Feuer]

Thinking about this more, I think my first sense can be made more
precise like this:

(getNF . makeNF $ v) must be indistinguishable from (force v) within
the Haskell language, and when evaluated to WHNF they must force the
same lazy IO to be performed (if any).

I still don't know how to specify the performance expectations.

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