System.Random instances for tuples

[Ryan Newton]

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.



On Thu, Apr 19, 2012 at 10:31 AM, Ryan Newton <rrnewton at gmail.com> wrote:

> 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 at 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.
>>
>>
>> ______________________________**_________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20120419/20eb6186/attachment.htm>