- Reactive - Haskell.org

Newbie Difficulty ..
by Tom Poliquin 22 Sep '09

22 Sep '09

I know that this is an advanced group but I am hoping someone can give us a little help .. [Boring History Begins] I and one of my students have been excitedly experimenting with Reactive. We're not Haskell pros but have written lots of Haskell code, including an HopenGL Logo, a computer architecture simulator, and an HopenGL conventional robot wall follower simulator. (screenshot and code are available here, http://www.softcomp.com/haskell/wallfollow/wf02.png http://www.softcomp.com/haskell/wallfollow/wf01.tar.gz ) Our goal is to rewrite the conventional wall follower robot simulation in Reactive. We're happy to publish it once it's working. Several months ago Jules Bean posted 'stars' (to the group) a demo of a reactive framework similar to, but not identical to Colin's. Inside 'stars' was a file containing several very simple reactive examples (very useful to us newbies). http://www.softcomp.com/haskell/wallfollow/JulesReactiveDemo.hs Source .. including support libraries (Deus subdirectory) is here, http://www.softcomp.com/haskell/wallfollow/JulesReactiveDemo.tar.gz After experimenting with these we wrote a reactive robot controller which is supposed to wall follow. This controller code produces a file (this way we didn't have to rewrite to GUI portion too) to be input later to a visual 'player'. Unfortunately it just hangs and produces no output. [Boring History Ends] Undaunted we stepped back and wrote an extremely simple thermostat / furnace controller. This exhibits the same untoward hanging behavior on a blocking read inside 'runReactor'. The code for the main program is given far below. Full code (including the Deus directory, where all of Jules support code resides) is here, http://www.softcomp.com/haskell/wallfollow/thermostat.tar.gz Reactive.hs is where most of the interesting support routines live, including 'runReactor' We know Reactive is a bit of the cutting edge and everyone is busy hacking (in the good sense) but any help would be greatly appreciated. Any docs or papers you deem appropriate would be greatly appreciated also. We've been to the standard places .. Colin's site, Less Meat .., Reactive Mailing list, Haskell site, Frob, Fran, Fr _fill-in-the-blank_ etc. I'm hoping we simply made some silly mistake cause by our tenuous understanding of Reactive. Could this be the 'lazy pattern matching' issue? (An example of this with a server/client example was given in Gentle Intro to Haskell which wouldn't work until it was 'primed' by a lazy pattern match. If it would be more appropriate we can try to convert it to Colins' style. Any help greatly appreciated, Tom --------- Thermostat / Furnace Controller --------- module Main where import System.IO -- Jules Reactive import Deus.Reactive import Data.Time.Clock --import Data.Time.Calendar --import Data.Time.Format ---------------------------------------------- constFun :: Double -> UTCTime -> Double constFun constval trash = constval constB :: Double -> Behaviour Double constB value = timeFunction (constFun value) ---------------------------------------------- furnaceUpdate :: Behaviour Double -> Event Int -> Behaviour Double furnaceUpdate furnace ticker = (switcher (constB 25.0) (fmap constB (accumE 25.0 (snapshotWith (\watts ticker -> (\temp -> temp+(watts/100.0))) furnace ticker)))) -------------------------------------------------------------------- controllerUpdate :: Behaviour Double -> Event Int -> Behaviour Double controllerUpdate temp ticker = (switcher (constB 0.0) (fmap constB (snapshotWith (\temp tick -> (600.0 - temp) / 1000.0) temp ticker))) ---------------------------------------------------------------- furnaceMain :: Event Int -> Event (IO ()) furnaceMain ticker = let watts = (controllerUpdate temp ticker) temp = (furnaceUpdate watts ticker) in fmap (\result -> putStrLn $ "Temp -> " ++ show result) (snapshotWith (\t tick -> "\n" ++ show t) temp ticker) ---------------------------------------------------------------- ---------- -- Main -- ---------- main = do --hSetBuffering stdin NoBuffering --hSetBuffering stdout NoBuffering ticker <- timewiseIterate 10000 (+1) 0 runReactor (furnaceMain ticker) putStrLn "Done .."

3 4

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

Clock skew corrections
by Robin Green 26 Aug '09

26 Aug '09

What happens if the system clock is running too fast, this is noticed, and the system clock is corrected, during a program run? I think this could break temporal monotonicity of occurrences in events, as FRP.Reactive.Internal.Clock doesn't know about system clock corrections. Am I right? If so, what, if anything, should be done about it? One rather inefficient approach would be to have a global mutable variable and a mutex for that variable, to record the last known time "reading" for the entire system, and a temporal adjustment factor (initially zero). If the difference between the last reading and the (adjusted) current reading was a positive number, that difference would be added to the temporal adjustment factor. This would prevent temporal monotonicity being broken. -- Robin

2 1

Fw: Plans for GHC 6.12.1: release candidate 14 September 2009
by Robin Green 19 Aug '09

19 Aug '09

Are there any outstanding GHC bugs relevant to reactive, that are not listed at the link below? Begin forwarded message: Date: Tue, 18 Aug 2009 15:03:43 +0100 From: Ian Lynagh <igloo(a)earth.li> To: glasgow-haskell-users(a)haskell.org Subject: Plans for GHC 6.12.1: release candidate 14 September 2009 Hi all, This is a summary of our plans for GHC 6.12.1. We are aiming to have the first release candidate out on the 14th September 2009. Until then, we plan to focus on the bugs in the 6.12.1 milestone, marked high priority; they are listed here: http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status… If there is a bug not in that list that is important to you, please let us know. Thanks Ian _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Robin

2 1

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 12 Jul '09

12 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

Using Reactive in a commercial video game - thoughts?
by Ryan Trinkle 16 Jun '09

16 Jun '09

I'm a co-founder of a game studio that will be writing in (primarily) Haskell. We're currently assembling the technology stack for our first game, and I'm very interested in FRP (Reactive in particular) as a way of making video game programming easier and less error-prone. However, from reading this list and discussing it with people in #haskell on irc.freenode.net, it seems that there may be issues blocking us from using it within our timeframe (we plan to release our first game around November). What known issues would prevent Reactive from being used today in a commercial video game? Would you anticipate the discovery of many critical issues in the future? What would it take to overcome these issues? Thanks, Ryan Trinkle

3 2

FRP, continuous time and concurrency
by Álvaro García Pérez 11 Jun '09

11 Jun '09

Hello, I'm trying to implement something like the Observer pattern in a functional setting. Some people told me that maybe I will find what I want in FRP. The Observer pattern enforces the propagation of changes in the subject to the observers, but in a way where concurrency is not considered, through the notify-update mechanism. Time is not considered because the updating methods are invoked in a synchronous way. Other way to say it is that time is a discrete value which is incremented by one with any subject change and the observers use a pooling strategy in every instance of time. The subject and the observers operate in the same thread. As far as I've seen (but I'm not sure if I'm right) FRP models behaviours and time as continuous entities (although practical implementations use discrete time and discrete sampling in event detection). You must represent the time explicitly and concurrency is used to model behaviors and events. Is there any interpretation of FRP without using concurrency? Can the time be modeled in a discrete fashion (as described for the Observer pattern)? I didn't find any example of that. Is it possible to model something like the Observer patern using the standard FRP conventions? Are these situations inside the aims of FRP? I think the Observer pattern and FRP are related somehow, but I cannot figure out how is this. Alvaro.

8 15