[reactive] Re: Re: Link to Tetris

[Thomas Davie]

On 16 Dec 2008, at 12:35, Claus Reinke wrote:

>> 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):
>> -- | Merge two 'Future' streams into one.
>> merge :: Ord t => Binop (FutureG t (ReactiveG t a))
>> -- The following two lines seem to be too strict and are causing
>> -- reactive to lock up.  I.e. the time argument of one of these
>> -- must have been _|_, so when we pattern match against it, we --  
>> block.
>> -- 
>> -- On the other hand, they patch a massive space leak in filterE.    
>> Perhaps
>> -- there's an unamb solution.
>> Future (Max MaxBound,_) `merge` v = v
>> u `merge` Future (Max MaxBound,_) = u
>> u `merge` v =
>>  (inFutR (`merge` v) <$> u) `mappend` (inFutR (u `merge`) <$> v)
>> -- What's going on in this 'merge' definition?  Try two different
>> -- future paths.  If u arrives before v (or simultaneously), then
>> -- begin as u begins and then merge v with the rest of u.  Otherwise,
>> -- begin as v begins and then merge u with the rest of v.  Because of
>> -- the left-bias, make sure u fragments are always the first argument
>> -- to merge and v fragments are always the second.
>
> hmm, I can find various bits of code that *test* for MaxBound, but
> are there actually any bits that *deliver* MaxBound?

Yes, listEG [] for example.

> Anyway, if I
> understand this part correctly, then testing for MaxBound shouldn't
> be privileged this way: just as the actual merge looks for the first
> of 'u' or 'v' to arrive, so checking, say, 'u' for MaxBound should  
> be a check on the first of 'u' and some artificial 'now' (left- 
> biased, so that 'u's MaxBound has a chance to come through, but with  
> an immediately available alternative 'now', so that the whole test  
> doesn't block if 'u' isn't available yet).

Yep, absolutely, the problem is that such a test that also checks for  
the MaxBound is very hard to implement in Haskell.  My thoughts at the  
moment include 1) using unamb to check for MaxBound, but this doesn't  
guarentee to squash the leak, only makes it likely. 2) Use some new  
ghc primitive along the lines of unsafeIsInWHNF :: a -> IO Bool to  
check whether I can find out if u or v is MaxBound yet.

Tom Davie