[Haskell-cafe] Is this a correct explanation of FRP?

[Paul Liu]

On Thu, Apr 5, 2012 at 4:30 AM, Ertugrul Söylemez <es at ertes.de> wrote:
> Paul Liu <ninegua at 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