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

[Ertugrul Söylemez]

Peter Minten <peter.minten at 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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120402/d426e7ce/attachment-0001.pgp>