# The Essence of FRP by Jozsef Hegedus at Helsinki FRP Meetup April 1, 2015

7 0 661

Uploaded on
05/10/2015

The Essence of FRP by Jozsef Hegedus at Helsinki FRP Meetup April 1, 2015

Comments (4):

By anonymous 2017-09-20

IMHO, Functional Reactive Programming (FRP) is in a sense a general way to solve cache invalidation.

Here is why: stale data in FRP terminology is called a glitch. One of FRP's goals is to guarantee absence of glitches.

FRP is explained in more detail in this 'Essence of FRP' talk and in this SO answer.

In the talk the `Cell`

s represent a cached Object/Entity and a `Cell`

is refreshed if one of it's dependency is refreshed.

FRP hides the plumbing code associated with the dependency graph and makes sure that there are no stale `Cell`

s.

Submit Your Video

By anonymous 2017-09-20

After reading many pages about FRP I finally came across this enlightening writing about FRP, it finally made me understand what FRP really is all about.

I quote below Heinrich Apfelmus (author of reactive banana).

So, in

my understandingan FRP program is a set of equations:`j`

is discrete: 1,2,3,4...`f`

depends on`t`

so this incorporates the possiblilty to model external stimuliall state of the program is encapsulated in variables

`x_i`

The FRP library takes care of progressing time, in other words, taking

`j`

to`j+1`

.I explain these equations in much more detail in this video.

EDIT:About 2 years after the original answer, recently I came to the conclusion that FRP implementations have another important aspect. They need to (and usually do) solve an important practical problem:

cache invalidation.The equations for

`x_i`

-s describe a dependency graph. When some of the`x_i`

changes at time`j`

then not all the other`x_i'`

values at`j+1`

need to be updated, so not all the dependencies need to be recalculated because some`x_i'`

might be independent from`x_i`

.Furthermore,

`x_i`

-s that do change can be incrementally updated. For example let's consider a map operation`f=g.map(_+1)`

in Scala, where`f`

and`g`

are`List`

of`Ints`

. Here`f`

corresponds to`x_i(t_j)`

and`g`

is`x_j(t_j)`

. Now if I prepend an element to`g`

then it would be wasteful to carry out the`map`

operation for all the elements in`g`

. Some FRP implementations (for example reflex-frp) aim to solve this problem. This problem is also known as incremental computing.In other words, behaviours (the

`x_i`

-s ) in FRP can be thought as cache-ed computations. It is the task of the FRP engine to efficiently invalidate and recompute these cache-s (the`x_i`

-s) if some of the`f_i`

-s do change.Original Thread