deepseq: instance NFData (a -> b)

[Ryan Scott]

I wouldn't be sad to see the instance go, although I do extract a minimal
amount of utility out of it. In any case, I doubt I'm going to convince
anyone, so let's just remove it :)

Ryan S.
On May 6, 2016 5:52 PM, "Edward Kmett" <ekmett at gmail.com> wrote:

> I have to admit the idea of duplicating the orphan instance module we have
> for Text.Show.Functions makes me queasy. It is a pretty ugly compromise
> that makes everyone unhappy, not really a model for future behavior. I'd
> rather drop the instance entirely but could be convinced.
>
> Sent from my iPad
>
> > On May 6, 2016, at 11:56 AM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
> >
> > I'm tentatively +1 on the idea of removing the NFData (a -> b) instance.
> >
> > Henning raises a good point that there are probably folks who rely on
> > that instance to make automatic deriving of NFData. (Disclaimer: the
> > phrase "folks" includes myself.) A similar scenario arises when
> > deriving Show instances, for which a compromise was made by putting
> > the Text.Show.Functions module in base, which does nothing but export
> > an orphan Show (a -> b) instance.
> >
> > Perhaps, if we wanted to retain the ability to use the NFData (a -> b)
> > instance in limited scenarios (e.g., when you're writing an
> > application and there's no risk of leaking orphan instances to other
> > users), then we could also introduce a Control.DeepSeq.Functions
> > module that exports an orphan NFData (a -> b) instance, and put a
> > giant warning at the top stating that such an instance should be used
> > responsibly. What say ye?
> >
> > Ryan S.
> > _______________________________________________
> > 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/20160506/97e1a25e/attachment.html>