Peter Minten <peter.min...@orange.nl> wrote: > Sorry, I don't understand this. Would it be correct to say that AFRP > shares the basic ideas of FRP in that it has behaviors and > events/signals and that the main difference comes from the way AFRP is > implemented?
Well, FRP is usually interpreted as dealing with time-varying values. The main selling point of FRP is the ability to combine those values like ordinary ones and let them react to events. AFRP offers the same functionality, but the underlying idea is different. To the user the difference becomes apparent when combining those special values (whatever you call them, I always thought "behavior" is a bad name). Also the values can implement certain semantics which would be impossible in the traditional concept, like a frame counter. > As I see FRP it has three components: the basic concepts, the > underlying theory and the way the libraries actually work. > > As far as I understand FRP (which is not very far at all) the basic > concepts can, simplified, be formulated as: > > * There are things which have a different value depending on when you > look at them. (behaviors) That's already specific to traditional FRP. In AFRP the value mutates. It's not a function of some notion of time. It is similar to a list. That list contains the current value as well as a description of the future of the value: newtype SF a b = SF (a -> (b, SF a b)) The current value and the future depend on a momentary input value of type 'a' (which usually comes from another SF). > "Normal" FRP theory expresses behaviors as "Time -> a" and events as > "[(Time,a)]". AFRP uses some kind of "signal function" to express > behaviors, or behaviors are signal functions and those functions > interact with events. Anyway AFRP uses a completely different > theoretical way of thinking about events and behaviors. A behavior from traditional FRP is a special case of a signal function. It's a 'stateless' signal function, i.e. one that never mutates. In both cases you would use switching combinators to react to events. > Netwire also uses AFRP but extends the theory with something called > signal inhibition. Like everything else it shares the basic concepts > of FRP. No, Netwire does things very differently. Note the total absence of switching combinators. Where in traditional FRP and regular AFRP you have events and switching in Netwire you have signal inhibition and selection. AFRP is really just changes the theory to establish some invariants. Netwire changes the whole paradigm. Review alterTime as expressed in the Netwire framework: alterTime = fullTime <|> halfTime This isn't switching. It's selection. If fullTime decides to be productive, then alterTime acts like fullTime. Otherwise it acts like halfTime. If both inhibit, then alterTime inhibits. This allows for a much more algebraic description of reactive systems. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/
signature.asc
Description: PGP signature
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe