Closed lehins closed 4 years ago
Here is rather short discussion on whether NFData instances for IO/STRef should exist: https://github.com/haskell/deepseq/pull/47
I think that these instances shouldn't exists since they only reduce reference to WHNF.
Thanks @Shimuuar for the link. Why everything drags for so long in Haskell? haskell/deepseq#16 has been discussed for 4 years now and still nothing happens. Just rip the bandage, remove the instances, and be done with it. Longer the inaction, the more people get to rely on those instances, then harder it becomes to remove them and more code gets broken in the end.
Considering the unknown future of NFData
instances for IORef
and STRef
, I prefer not to deal with this issue here in random
. Closing.
Why everything drags for so long in Haskell?
Laziness?
@Shimuuar I don't think it is laziness, I think it is inability to make an executive decision. There is not much work involved in solving an issue like that.
I just couldn't resist joking about haskell's model of evaluation. I do agree that this sort of indecision seems to be endemic in haskell ecosystem.
@Shimuuar I don't think it is laziness, I think it is inability to make an executive decision. There is not much work involved in solving an issue like that.
There are too many clever people in Haskell mostly with valid reasons for what they suggest. I don't know what the answer is. random
itself could have been improved incrementally but this sort of discussion held back any such improvements.
Add NFData instances for
STGenM
,IOGenM
,AtomicGenM
andStateGenM
IORef and STRef have NFData instances. There is no reason not to derive them for mutable generators as well. Very useful for benchmarks and such.