Alright, as a library proposal we need a discussion period and a deadline for decision.
As the maintainer, I personally have no objection but am completely agnostic on the choice between the design alternatives:
- Use split, don't add strictness to other tuple components
- Don't use split, inject additional strictness.
Honestly, since random instances will never include any "interesting" computation I'm not sure why one would ever mind the extra strictness.
Perhaps the documentation for the instances should say that bringing the tuple itself to WHNF may evaluate any subset of the tuple components...
-Ryan
On Thu, Apr 19, 2012 at 10:18 AM, Henning Thielemann
<lemming@henning-thielemann.de> wrote:
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.