deepseq: instance NFData (a -> b)
Edward Kmett
ekmett at gmail.com
Fri May 6 21:52:08 UTC 2016
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
More information about the Libraries
mailing list