But it's worth mentioning that we have an accepted but not yet released library proposal to factor "split" out into its own type class.<div><br></div><div><br></div><div><div><br><div class="gmail_quote">On Thu, Apr 19, 2012 at 10:31 AM, Ryan Newton <span dir="ltr"><<a href="mailto:rrnewton@gmail.com">rrnewton@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Alright, as a library proposal we need a discussion period and a deadline for decision.</div><div><br></div><div>
As the maintainer, I personally have no objection but am completely agnostic on the choice between the design alternatives:</div>
<div><ul><li>Use split, don't add strictness to other tuple components</li><li>Don't use split, inject additional strictness.</li></ul><div>Honestly, since random instances will never include any "interesting" computation I'm not sure why one would ever mind the extra strictness.</div>
</div><div><br></div><div>Perhaps the documentation for the instances should say that bringing the tuple itself to WHNF may evaluate any subset of the tuple components...</div><span class="HOEnZb"><font color="#888888"><div>
<br></div><div> -Ryan</div></font></span><div class="HOEnZb"><div class="h5"><div><br></div>
<br><div class="gmail_quote">On Thu, Apr 19, 2012 at 10:18 AM, Henning Thielemann <span dir="ltr"><<a href="mailto:lemming@henning-thielemann.de" target="_blank">lemming@henning-thielemann.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I find the tuple instances for Random useful.<div><br>
<br>
<br>
On Tue, 17 Apr 2012, Yitzchak Gale wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm guessing that this was left out because of its<br>
surprising side-effect of adding strictness to the<br>
first component: If you try to get the value of the<br>
second component, the first one is forced.<br>
</blockquote>
<br></div>
I'm not surprised. Without this instance I would wrap 'randomR' in a State monad and then do a<br>
liftA2 (,) (State random) (State random)<br>
which yields the same behavior.<br>
<br>
I am thinking about whether your argument reveals a problem for lists. If you do<br>
unzip (randoms g)<br>
then evaluating one of the result lists will also evaluate parts of the other list. However, this is true for many applications of unzip.<br>
<br>
For me @randoms :: g -> [(a,a)]@ looks nicer than<br>
@case split g of (g0,g1) -> zip (randoms g0) (randoms g1)@.<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For example, imagine that in randomR the<br>
computation for the lower bound on the first<br>
component is expensive or bottom, and you<br>
only ask for the second component in the<br>
calling code.<br>
</blockquote>
<br></div>
Isn't this the same problem as in Ix tuple instances?<br>
<br>
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.<br>
<br>
<br>
What about QuickCheck.Arbitrary instance? As far as I remember the current version of QuickCheck has tuple instances.<div><div><br>
<br>
______________________________<u></u>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br></div></div>