Reactive

Download

reactive@haskell.org

September 2009

4 participants
2 discussions

Newbie Difficulty ..
by Tom Poliquin 21 Sep '09

21 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