Re: deepseq: instance NFData (a -> b)

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" 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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries