I find the tuple instances for Random useful. On Tue, 17 Apr 2012, Yitzchak Gale wrote:
I'm guessing that this was left out because of its surprising side-effect of adding strictness to the first component: If you try to get the value of the second component, the first one is forced.
I'm not surprised. Without this instance I would wrap 'randomR' in a State monad and then do a liftA2 (,) (State random) (State random) which yields the same behavior. I am thinking about whether your argument reveals a problem for lists. If you do unzip (randoms g) then evaluating one of the result lists will also evaluate parts of the other list. However, this is true for many applications of unzip. For me @randoms :: g -> [(a,a)]@ looks nicer than @case split g of (g0,g1) -> zip (randoms g0) (randoms g1)@.
For example, imagine that in randomR the computation for the lower bound on the first component is expensive or bottom, and you only ask for the second component in the calling code.
Isn't this the same problem as in Ix tuple instances? Are you sure that the bounds for the first component are computed if the second component is evaluated? I think only the 'g' is forced. What about QuickCheck.Arbitrary instance? As far as I remember the current version of QuickCheck has tuple instances.