> ..until further notice, just assume "broken".<br><br>Useful to know. I shall postpone its use in critical projects.<br><br>BTW, s/joinMaybes/justE works quickly, in minimal CPU and memory. Forgot about that function. Curious that the operational semantics have become so odd though; I'm used to denotational ones being off -- late updates and so forth -- but I haven't come across quite that level of resource consumption in reactive code before.<br>
<br>Freddie<br><br><div class="gmail_quote">2009/6/10 Svein Ove Aas <span dir="ltr"><<a href="mailto:svein.ove@aas.no">svein.ove@aas.no</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/6/10 Freddie Manners <<a href="mailto:f.manners@gmail.com">f.manners@gmail.com</a>>:<br>
<div><div></div><div class="h5">> This is a silly example. Console lines "b = x" update the value of b; "c =<br>
> y" likewise; lines starting "a" cause the current value of a to be printed.<br>
><br>
> module Main<br>
> where<br>
><br>
> import FRP.Reactive<br>
> import FRP.Reactive.LegacyAdapters<br>
> import Data.List<br>
> import Control.Monad<br>
> import Control.Concurrent<br>
> import Control.Applicative<br>
><br>
> parseEvent :: String -> Event String -> Event Integer<br>
> parseEvent s = fmap read . joinMaybes . fmap (stripPrefix s)<br>
><br>
> main :: IO ()<br>
> main = do<br>
> cl <- makeClock<br>
> (s,e) <- makeEvent cl<br>
> forkIO . forever $ getLine >>= s<br>
> let b = stepper 0 $ parseEvent "b =" e<br>
> let c = stepper 0 $ parseEvent "c =" e<br>
> let p = parseEvent "a" e<br>
> let a = liftA2 (+) b c -- the only interesting line<br>
><br>
> adaptE . fmap print $ snapshot_ a p<br>
><br>
> So yes, this does use explicit concurrency because "feeding" the reactive<br>
> events (with getLine) and printing the answers must happen in different<br>
> threads.<br>
><br>
> Interestingly, this fairly simple program gobbles CPU and RAM on<br>
> reactive-0.11, as well as running with a bit of a lag. Could joinMaybes be<br>
> to blame? I don't know how happy the Monad instance of Event is these days.<br>
><br>
</div></div>"Fundamentally broken" about covers it.<br>
<br>
Well, to be specific, joinE is broken, and looks hard to fix.<br>
The Monoid instance for Event is also broken, but I think only when<br>
all Events involved are finite.<br>
<br>
Further, I was trying to fix it, but GHC is broken.<br>
<br>
I'd also like to note that LegacyAdapters is broken. I've got a fix<br>
for the broken bits, which happens to break everything else. Blocked<br>
on another GHC bug, though.<br>
<br>
..until further notice, just assume "broken".<br>
<br>
--<br>
<font color="#888888">Svein Ove Aas<br>
</font></blockquote></div><br>