On Thu, Apr 5, 2012 at 4:30 AM, Ertugrul Söylemez wrote:

Paul Liu 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