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

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.

On Fri, 6 May 2016, Ryan Scott wrote:
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?
Since we got several problematic instances over time, we might also consider my proposal of warning about these instances on user demand: http://mail.haskell.org/pipermail/libraries/2016-March/026859.html https://ghc.haskell.org/trac/ghc/ticket/11796

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

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

On 05/06/2016 11: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.
+1 KILL IT! KILL IT WITH FIRE!... ahem. Regards,

Let's turn this around, is there anybody actually in favor of keeping
the instance?
On Sat, May 7, 2016 at 4:05 AM, Bardur Arantsson
On 05/06/2016 11: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.
+1
KILL IT! KILL IT WITH FIRE!... ahem.
Regards,
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On Sat, 7 May 2016, Edward Kmett wrote:
Let's turn this around, is there anybody actually in favor of keeping the instance?
Looking in the git-logs I found git-commit 3b5c957ce7bba7b63b4483a43c6762c3f5d8ee28 by Herbert Valerio Riedel saying: "Merge `deepseq-generics` into `deepseq` ..." and it points to the proposal: http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/23031 So, I guess Herbert must be in favor of the instance because he added it. :-) And this commit confirms that the instance NFData (a->b) was a side product of Generics support.
participants (4)
-
Bardur Arantsson
-
Edward Kmett
-
Henning Thielemann
-
Ryan Scott