July 2009 - Reactive - Haskell.org

Temporal mechanics
by Svein Ove Aas 12 Sep '09

12 Sep '09

Specifically, the implementation of Time. I have some options, and would like your opinion. Facts: - There are two serious options for joining (eg. join :: m (m a) -> m a) futures, and by extension events/reactives/behaviour. Picking the largest time value, or summing them. Both are useful in different scenarios. - There are essentially two variants of time; absolute and relative. Absolute time might be represented as nanoseconds since 1970, while relative would be relative to some arbitrary starting point. Currently, and in conal's reactive, they are not differentiated. After giving it some thought, I believe that it would be reasonable to split Time in two types; one for representing absolute time, one relative; of course parametrizing the event/etc. types on the Time type the same way it's done in reactive. The join operators would be implemented as using a Monoid instance on the time types, which act a bit differently, depending. When mappending absolute times, the max of the two times would be used, with mempty of course MinBound. For relative times, the times would be summed; mempty = 0. One thing I'm not entirely sure about is the interface between absolute and relative time. Probably, the best option is to have a specialized join function for absolute :. relative -> absolute; other requirements will likely surface over time. This setup lends itself well to many common cases. When mapping one event occurence to an event consisting of multiple reactions spread over time, the reactions are naturally relative to the original occurence; using a sum function to join them, you won't have to care about exactly when that original happens. What do you think? Sounds reasonable? Lastly one ability that would take implementation effort all out of its proportion to its usefulness is the ability to subtract two absolute times, giving a relative time, and have that time provide partial information at any point before both absolute times are fully defined. If any of you would like that, and have a good reason, now is the time to speak up; doing it later would only increase the needed effort (though not beyond the bounds of Time.hs). -- Svein Ove Aas

3 2

New implementation: Reactant (99% incomplete)
by Svein Ove Aas 30 Jul '09

30 Jul '09

In the interest of throwing code out early, at http://github.com/Baughn/Reactant/tree/master there is now the first draft of a different approach to Conal-style FRP. Well, I say "first draft", but the code in there currently only implements ITime - eg. Improving Time. Fortunately that's also the hardest bit; the source of most of the bugs, and the reason to use unamb. This implementation doesn't use unamb, though. Instead, I'm using a push-style approach, where the various function calls - compare, etc. - use semaphores to block until the ITimes they are comparing are sufficiently defined for them to return an answer. It's my hope that, although this approach is also quite bug-prone, I will be able to side-step the issues with unamb this way. If nothing else, performance should increase noticably; there is no need for this system to fork any threads except to deal with timeouts, thus forking happens considerably less often than with unamb. I'll hopefully have more for you in a few days. Until then, you may be entertained by looking closely at the rather eldritch code, and if anyone spots a potential bug, that's just a bonus. -- Svein Ove Aas

4 3

The current state of reactive (or: I would like to start experimenting but keep on hitting walls)
by Mathijs Kwik 26 Jul '09

26 Jul '09

Hi all, I found the blogposts on http://netsuperbrain.com/blog/posts/introducing-reactive-events and I really like the semantics. Most FRP stuff seems to have a strong focus on UI, but this seemed more generic to me. I have done some networking daemons in the past, handling threads and channels myself, but found it to be quite error-prone, especially when there's shared state involved. This is probably mostly because I'm still just learning haskell and FP in general, but abstracting stuff the way reactive tries to (defining what stuff _is_ rather than how it should do it) seems to be a lot clearer and more functional. I wanted to get experimenting right away, so I needed a way to bind reactive to IO. For getting familiar, just interacting with console or a socket would be enough. I found http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2109 that's supposed to simply adapt stdin+stdout to reactive. As others pointed out, makeEvent switched the event and the sink, and I found I had to use exactNB instead of exact to make it compile with reactive 0.11 Apart from compiling, running seems to be a problem. Most examples I tried (especially metronome) will make 1 thread run 100% cpu and eat memory, while nothing happens. After some googling and reading the mailing list, I noted that reactive seems to be a very quickly moving target (breaking API every release). I'm ok with that, pre 1.0 stuff should break, as it allows radical changes to be tried out. I'm not gonna use anything for real projects yet, so moving along with reactive's changes isn't an issue. The thing is (for me, but probably for lots of other people who would like to get more familiar with FRP), it's very hard to find examples that just work. Maybe just a simple getting-started application on the wiki that stays up-to-date with the current release? Anyway, about the problem I ran into. I did some googling and IRCing and read about a bug that's hard to fix (ghc bug). Is my problem related to that bug or is there something else I need to change? About the ghc bug itself, and other stuff being "fundamentally broken" (as I read on the list), is there any progress? (as in: ghc 6.12 has this fixed) Or should I concider reactive to be more like a research project, that won't be ready for real use (or experimental use) for at least a few years? I don't mean to be trolling here, just want to know if it's "safe" to track reactive and try some non-critical apps on it, knowing it's goal is to become stable and usable. Anyway, Thanks for all hard work, even if not directly usable, it gave me a clearer view on how to think about interactive programs. Mathijs

1 0

More on delayed switching
by Patai Gergely 11 Jul '09

11 Jul '09

Hello all, I opened a thread some time ago where I asked whether it's enough to have only immediate switching. But it dawned on me that Reactive switches are actually all delayed, since even though the delay is infinitesimal in principle, we still have to wait for the next point of observation until we can see its effect. This is a huge problem in practice, because this way every stateful signal imposes a delay equal to the length of the period between observations. Here's a simple test case for illustration: > import Control.Applicative > import FRP.Reactive > > tick :: Event () > tick = atTimes [0..] > > behs :: [Behavior Double] > behs = pure 1 : map (integral tick) behs > > eventList :: Event a -> [a] > eventList e = x : eventList e' > where (x,e') = firstRestE e > > testBeh :: Behavior a -> [a] > testBeh b = take 10 $ eventList (snapshot_ b tick) > > test :: IO () > test = mapM_ (print . testBeh) (take 5 behs) Running test prints the following: [1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0,1.0] [0.0,0.0,1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0] [0.0,0.0,0.0,1.0,3.0,6.0,10.0,15.0,21.0,28.0] [0.0,0.0,0.0,0.0,1.0,4.0,10.0,20.0,35.0,56.0] [0.0,0.0,0.0,0.0,0.0,1.0,5.0,15.0,35.0,70.0] I ran into the very same problem when working on the first version of Elerea. Transfer functions in version 0.1.0 behave exactly the same way, and I switched to immediate transfer functions from 0.2.0. The difference is obvious if you look at the breakout example in action: in 0.1.0, the ball takes long to react to collisions, since the dependency cycle consists of three items (bricks, velocity, position), so any change takes just as many frames to propagate. From 0.2.0 onwards, collisions are much more accurate without any change in the example code. Sure, it is possible to work around the delay by combining the switching value with the one that caused its switch, but this adds a lot of complexity to the code on the user end. You can make life easier by introducing immediate versions as helper functions, but then you just reintroduced this distinction. Of course this is not surprising, since neither delayed nor immediate switching is sufficient on its own. But this means that Reactive should support both out of the box and not encourage ad hoc workarounds that are likely to break in unexpected ways. Also, immediate switching seems the more sensible default, because it's more straightforward to derive the delayed version from it than the other way around, and it is what we need most of the time. Are there any plans to address this problem? Or a completely new angle to look at it from? Gergely -- http://www.fastmail.fm - Faster than the air-speed velocity of an unladen european swallow

2 2

Event's Monad instance and joinE
by Chris Lesniewski-Laas 11 Jul '09

11 Jul '09

Hi. I've been experimenting with using Reactive as the basis of a network daemon I'm working on, with the top-level type Event Packet -> Event Packet. I've run into a difficult-to-debug strictness problem with the Monad instance for EventG, at least when used together with makeEvent. Here's a minimal test program that shows the problem: > import FRP.Reactive > import FRP.Reactive.LegacyAdapters > import Control.Concurrent > import Control.Monad > > my_event :: IO (Event Char) > my_event = do > (char_sink, char_event) <- makeEvent =<< makeClock > forkIO $ forever $ char_sink =<< getChar > return char_event > > main = do > chars <- my_event > adaptE $ do c <- chars ; return (print c) Running this program consumes 100% of CPU and doesn't respond to input. On the other hand, replacing the last line with > adaptE $ print `fmap` chars does what you'd expect (prints each character read from stdin as it is received). I'm pretty sure what's happening here is adaptE evaluating joinE, which is in turn evaluating its recursive call to joinE without being properly lazy and waiting for the next occurrence of Event (Event Char), leading to an infinite loop. I've played around with the definition of joinE, but I don't have a sufficiently good mental model of the evaluator to figure out what needs to become stricter or lazier to fix this problem. In any case, my changes have either resulted in stack overflows or evaluating mempty. Perhaps I am misunderstanding the contract for Event's Monad instance. Is there a reason why it shouldn't be used with makeEvent or even adaptE? mkUpdater would be a poor substitute for adaptE, since a network daemon doesn't have any obvious equivalent to a graphical program's idle loop; ideally the output should be driven by incoming packets. Thanks, Chris

3 3