On Thu, Apr 5, 2012 at 4:30 AM, Ertugrul Söylemez <e...@ertes.de> wrote: > Paul Liu <nine...@gmail.com> wrote: > >> > 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. >> >> AFRP can do this through ArrowChoice. Maybe you can explain the >> concept of "inhibition" in more detail? >> >> I fail to grasp why this is making switches obsolete. The idea of >> switch is to completely abandoning the old state. See the broken >> pendulum example. > > Some of this can be done through ArrowChoice. The difference is > comparable to why server parts form a monoid in Happstack. You don't > have to decide when a server part reaches a request. You let the server > part decide itself. In other words ArrowChoice forces you to deal with > events in the application itself: > > -- Library code: > x = x' > y = y' > > -- Application code: > proc inp -> do > r <- request -< () > if p r > then x -< inp > else y -< inp > > Signal inhibition allows the component wires themselves to deal with the > events and you as the higher level programmer to just stick the wires > together: > > -- Library code: > x = proc inp -> do requireReq -< (); x' -< inp > y = y' > > -- Application code: > x <|> y
I'm curious as to how this plays out with the usual arrow compositions. How does x *** y behave when x inhibits? what about z >>> x? This cannot replace switching though, since the structure of your arrows cannot change dynamically, while with switches it can. -- Regards, Paul Liu _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe