<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">Yes indeed. The issue is that if you know one of the events will never
happen again, what you want to do is stop merging, and throw the
never-occurring event in the bin. Unfortunately, to pattern match
against the never occurring event then blocks checking whether the
match works or not :(.</blockquote><div><br>I'm trying to understand what the problem is here. I think the not-yet-known values are all wrapped with a NoBound and so should pass right by the MaxBound pattern matches without blocking.<br>
<br> - Conal<br></div><br><div class="gmail_quote">On Tue, Dec 16, 2008 at 2:56 AM, Thomas Davie <span dir="ltr"><<a href="mailto:tom.davie@gmail.com">tom.davie@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;">
<div class="Ih2E3d"><br>
On 16 Dec 2008, at 11:50, Claus Reinke wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Seems to be partially timer- and partially event-merge-related:<br>
if I compile with -threaded, the pieces do not move at all on their<br>
own, but as long as I keep pressing "down", the game appears<br>
playable as intended; if I compile without -threaded, the pieces<br>
move occasionally, but the effects of keyboard input are entirely<br>
unpredictable.<br>
</blockquote>
<br>
I've noticed this behavior in since the last couple of days, So at a guess a bug got introduced<br>
somewhere along the line. The merge issue is known -- at the moment, an occurrence doesn't<br>
appear in the output until it's known whether or not the other event ever occurs, which isn't<br>
ideal. Unfortunately, the obvious fix for the issue creates a large memory leak, I've been<br>
playing with a few ways to fix this.<br>
</blockquote>
<br>
Thanks for the info, Tom,<br>
<br>
where can I find more details about this merge issue? Given that<br>
FRPLs are traditionally synchronously concurrent languages, this<br>
is rather surprising: when sampling anything, one knows about<br>
everything's values _now_, which should be sufficient for merge,<br>
no matter whether the other event might or might not happen later.<br>
</blockquote>
<br></div>
Yes indeed. The issue is that if you know one of the events will never happen again, what you want to do is stop merging, and throw the never-occurring event in the bin. Unfortunately, to pattern match against the never occurring event then blocks checking whether the match works or not :(. The particular interesting bit of code is in PrimReactive.hs (Conal's comments here):<br>
<br>
-- | Merge two 'Future' streams into one.<br>
merge :: Ord t => Binop (FutureG t (ReactiveG t a))<br>
<br>
-- The following two lines seem to be too strict and are causing<br>
-- reactive to lock up. I.e. the time argument of one of these<br>
-- must have been _|_, so when we pattern match against it, we-- block.<br>
-- <br>
-- On the other hand, they patch a massive space leak in filterE. Perhaps<br>
-- there's an unamb solution.<br>
<br>
Future (Max MaxBound,_) `merge` v = v<br>
u `merge` Future (Max MaxBound,_) = u<br>
<br>
u `merge` v =<br>
(inFutR (`merge` v) <$> u) `mappend` (inFutR (u `merge`) <$> v)<br>
<br>
-- What's going on in this 'merge' definition? Try two different<br>
-- future paths. If u arrives before v (or simultaneously), then<br>
-- begin as u begins and then merge v with the rest of u. Otherwise,<br>
-- begin as v begins and then merge u with the rest of v. Because of<br>
-- the left-bias, make sure u fragments are always the first argument<br>
-- to merge and v fragments are always the second.<br>
<br>
<br>
Bob</blockquote></div><br>