Talk:FRP explanation using reactive-banana

Hello,

I think the current version of this introductory page introduces too many concepts at the same time. I would like to do a major rewrite to simplify the exposition and make it more accessible. As this would be a significant change and I am new to this wiki, I have re-written the first few sections and would like some feedback from folks before editing the page per se.

The sample revised first few sections is what follows...

This is an attempt to explain Functional Reactive Programming (FRP) to someone with no previous exposure. After reading this, you should have an intuition for what FRP is and also be able to understand the reactive-banana examples.

FRP concepts, such as behaviors and events, can be confusing. We avoid these at first and instead use spreadsheets as a motivating example. After the basic ideas are explained, we then introduce reactive-banana syntax together with an example of how to work with behaviors and events. Finally, to help you understand reactive-banana's haddock comments, we present some theory on time-varying functions and show how to implement events and behaviors with pure functions.

The version of reactive-banana used here is 0.8.0.0.

Reactive Programming for the masses: the spreadsheet

Most of us are familiar with spreadsheets. Consider a simple spreadsheet where we have a list of products that we sell and want to compute their price with a Value Added Tax (VAT) added. We might have cells A1 to A10 contain the raw prices of our products and cell B1 contain the current VAT rate (say 19 for a 19% VAT). In cells C1 to C10 we'd like to see the prices including VAT.

In cell C1, we could have a formula: =A1*(1+B1/100), in cell C2 =A2*(1+B1/100) and so on. That way, if A1 contains $100, C1 would contain $119.

But what if the government, in its eternal quest to reduce the budget deficit, raises the VAT rate to 20%? We'd simply adjust cell B1, just change it to 20. And like magic all the C cells are updated.

Although this may seem mundane, it is actually a very good example of reactive programming. We didn't tell the C cells to update; they updated on their own because a value that they depend on (cell B1) changed. Reactive programming is a way for programmers to obtain this kind of “auto-updating” functionality.

From cells to boxes: generalizing the spreadsheet

Spreadsheets are nice, but if we want to truly get a feel for FRP we'll have to think beyond them. If we look at a spreadsheet at an abstract level, it pretty much consists of cells of two types: value cells (19) and formula cells (=A1*(1+B1/100)). Let's lose the reference to spreadsheets and talk about boxes.

Assume, for now, that there are two kinds of boxes: formula boxes and value boxes. Both support a “get” operation that returns their current value. Value boxes additionally support a “set” operation that sets the value.

Formula boxes can contain any kind of pure function. They can also refer to the values of other boxes (both formula and value boxes). Value boxes don't have a function inside them, they have a value.

The translation of cell C1 of our VAT spreadsheet to this world of boxes is a formula box fIncl1 containing the expression get(vExcl1) * (1 + get(vVat) / 100). This expression uses two value boxes: vExcl1 and vVat that are the translations of cells A1 and B1 respectively.

Just like the spreadsheet updates cell C1 every time cells A1 and B1 change. FRP would update the value of fIncl1 every time the boxes vExcl1 and vVat change. That is, every time we execute the operation get(fIncl1) the value produced would depend on the latest values of the boxes vExcl1 and vVat’’.

In spreadsheets, value cells can contain simple types such as strings, numbers and dates. Let’s generalize that and allow our value boxes to contain any Haskell type, even complex ones like IO actions and functions.