> It's more like "Seed → [a]". IO is not really needed here.<br>You're absolutely right. I stand corrected.<br><br>> 1. One may want to generate values of different types and/or distibutions.<br>Yes, I saw this limitation before. But you can just generate one infinite list (and then one seed) per distribution, right?<br>
Or could you generate something homomorphic to [(Random a) => a]? (Each element would then basically be a closure containing the current Seed)<br><br>> 2. No way to make snapshot of generator state.<br>You mean the current seed?<br>
You don't need to access that if you only consume PRNs from the infinite list(s), and that during the whole program.<br><br>> 3. Laziness overhead. It may be significant if you try to squeeze last bit of performance.<br>
I'm afraid that if you're frightened by the laziness overhead then you won't use Haskell.<br>I'm kidding, but it's just I don't picture the overhead being so huge in that case. What so big would the runtime need to keep in memory except for the closure that generates the infinite list?<br>
<br><div class="gmail_quote">2012/2/10 Aleksey Khudyakov <span dir="ltr"><<a href="mailto:alexey.skladnoy@gmail.com">alexey.skladnoy@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 10.02.2012 18:38, Yves Parès wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I just thought about something: basically all these APIs provides a "IO<br>
[a]" (where a is a randomly generable type) function.<br>
Is there a problem with the approach that is to rely on lazy evaluation<br>
to pass to pure code (either explicitely or through State) the infinite<br>
list generated in IO and consume its head each time we need a random value?<br>
Because there is no issue such as resource holding, like in the case of<br>
file reading and enumerators, which would make lazy IO a not so good<br>
approach...<br>
<br>
</blockquote>
<br></div>
It's more like "Seed → [a]". IO is not really needed here. I can see<br>
following problems. None are real showstoppers (except maybe 2)<br>
<br>
<br>
1. One may want to generate values of different types and/or<br>
distibutions. This is easily solved by state monad. But I can't<br>
see advantage over wrapped ST.<br>
<br>
2. No way to make snapshot of generator state.<br>
<br>
3. Laziness overhead. It may be significant if you try to sqeeze last<br>
bit of performance.<br>
</blockquote></div><br>