Oh, you're right. Here are some thoughts.<br><br>You want the list you get back to only contain values in WHNF. This differs from mergeIO & co., which are simply evaluating the spine of the list, and don't even look at the values. <br>
<br>I would also consider it bad style to be fully polymorphic in this case, as you require polymorphic seq, which is evil (though I don't have the space to argue this right now :-). Unamb would be bad style, also, since your semantics are nondeterministic and so you wouldn't meet the precondition. Surely your result would have to be in IO. ("amb" would be okay)<br>
<br>Here is how I would do it:<br><br><font face="courier new,monospace">chooseIO :: [IO a] -> IO [a]<br>chooseIO xs = do<br> chan <- newChan<br> let eval io = forkIO (io >>= writeChan chan)<br> forkIO $ mapM_ eval xs<br>
getChanContents chan<br></font><br>(The list never ends in this case, even when xs is finite. I think it's possible to make the result finite with the argument is, and maintain good GC properties, but it would take some care)<br>
<br>The reason I take a list of [IO a] is to avoid polymorphic seq; the elements of the list have built in what it means to evaluate them. This also buys you more flexibility (but also fewer guarantees...).<br><br>For the working Haskeller, it is safe to avoid all this pedantic zealotry... I'm just being a purist.<br>
<br>Luke<br><br><br><br><div class="gmail_quote">On Tue, Mar 10, 2009 at 5:31 PM, Anatoly Yakovenko <span dir="ltr"><<a href="mailto:aeyakovenko@gmail.com">aeyakovenko@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
i think this would still force me to evailuate the whole list, right?<br>
i would want something that pipes the results into a channel that i<br>
can lazyly read as the results are available.<br>
<div><div></div><div class="h5"><br>
On Tue, Mar 10, 2009 at 2:44 PM, Luke Palmer <<a href="mailto:lrpalmer@gmail.com">lrpalmer@gmail.com</a>> wrote:<br>
> I think nmergeIO . map (:[]) should do the trick.<br>
><br>
> Luke<br>
><br>
> On Tue, Mar 10, 2009 at 3:41 PM, Anatoly Yakovenko <<a href="mailto:aeyakovenko@gmail.com">aeyakovenko@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hmm, yea, actually that makes sense. What i am looking for is<br>
>> something that maps over a list and returns the list in order which<br>
>> the values are evaluated. looks like i can implement that pretty<br>
>> easily with unamb.<br>
>><br>
>> On Tue, Mar 10, 2009 at 2:33 PM, Luke Palmer <<a href="mailto:lrpalmer@gmail.com">lrpalmer@gmail.com</a>> wrote:<br>
>> > Although it is not formally specified, my intuition for the<br>
>> > specification is<br>
>> > that order is preserved within each of the lists.<br>
>> ><br>
>> > Luke<br>
>> ><br>
>> > On Tue, Mar 10, 2009 at 2:50 PM, Anatoly Yakovenko<br>
>> > <<a href="mailto:aeyakovenko@gmail.com">aeyakovenko@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> do nmergeIO or mergeIO preserve order? or not preserve order?<br>
>> >> _______________________________________________<br>
>> >> Haskell-Cafe mailing list<br>
>> >> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
>> >> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br>