Bank Account

[Jack Waugh]

A bank account is characterized by a _statement_, which is a list of transactions giving date, amount, description, and new balance.  Any number of agents can communicate with a bank account.  They can ask for the latest statement, and they can attempt to withdraw.  The bank account's response to an attempt to withdraw money is either "OK, here's your money" or "Buzz off; your request would overdraw me and I won't allow that."

How do we implement a bank account in Reactive Demand Programming?

[David Barbour]

A bank account must be modeled with a stateful resource. There are a number of generic state models that could do the job, e.g. recording a history of demands, or reactive term rewriting. In this didactic case, we could use a very simple state model: a tuple space allows agents to 'insert' a sentence, typically modeled as a tuple, by holding it as a demand. (There are a number of ways to support deletion, but they aren't relevant for this problem.) We could use tuple space whose sentences represent transactions, and we could potentially use multiple tuple spaces to separately record proposed, accepted, and rejected transactions. By gathering data from the tuple spaces, we can also present a statement.

In case of multiple, simultaneous proposed withdrawals, it is possible that one or more will overdraw after all the others are applied. Most programming paradigms - actors, for example - would inflict a non-deterministic serialized ordering on withdrawal requests, basically racing to win the money. With RDP, a set of proposed transactions would be observed together, and developers would need to express an explicit decision - e.g. by filtering the set - for which transactions will 'win' in this case. This decision could be highly arbitrary, e.g. based on agent identifier, or favoring small transactions over large ones. It could also be explicitly made non-deterministic, e.g. by invoking a constraint model. But, in general, such problems are always explicit in RDP.

On Wed, Sep 3, 2014 at 7:29 AM, Jack Waugh <jv2a...@gmail.com> wrote:

A bank account is characterized by a _statement_, which is a list of transactions giving date, amount, description, and new balance.  Any number of agents can communicate with a bank account.  They can ask for the latest statement, and they can attempt to withdraw.  The bank account's response to an attempt to withdraw money is either "OK, here's your money" or "Buzz off; your request would overdraw me and I won't allow that."

How do we implement a bank account in Reactive Demand Programming?

--
You received this message because you are subscribed to the Google Groups "reactive-demand" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reactive-dema...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jack Waugh]

Is a tuple space to be implemented using RDP, or in another programming paradigm but callable from within RDP?  Or is it a primitive in RDP?

On Wednesday, September 3, 2014 12:44:19 PM UTC-4, David Barbour wrote https://groups.google.com/d/msg/reactive-demand/wSI3pVfOjy4/_fATwmXlt0AJ

[David Barbour]

Much like mutable variables are primitives in imperative programming, we need at least one primitive state model available for reactive demand programming. 

Assuming we have one sufficiently generic state model, everything else - including tuple spaces - can be implemented above it using RDP behaviors. We might still want a few specialized primitives for reasons of performance, safety, disruption tolerance, and so on. Specializations are also useful in imperative systems, where we might benefit from single-assignment variables and similar. But we can work without specialized models.

Primitive state models for RDP must meet requirements for causal commutativity and spatial idempotence. 

This can be achieved at least two ways. 

1) We can develop state models that are influenced by a *set* of simultaneous demands. Simple discrete state models (including tuple spaces) can be modeled in terms of a fixpoint function `(state * Set of Inputs) → state`. The function is a little more sophisticated if we also want to include temporal semantics, such as expiration of tuples, or motion in a physics simulation, but the same idea generally applies. 

2) Alternatively, we can prevent violation of causal commutativity and spatial idempotence by simply limiting developers to a single writer, e.g. via substructural (affine and linear) types. Substructural types are an excellent complement for RDP, but aren't strictly necessary. Anything you can do with substructural types, you can do without them... the patterns are just a little more ad-hoc and have more dynamic failure cases.

Hybrids of these approaches are also viable. There are many 'generic' state models that meet RDP's requirements - an infinity of them, really, and an RDP language can be designed such that users can define new, ad-hoc state models in terms of pure functions [1][2].

Aside: I only got a real grasp of state for RDP in March 2013. In late 2011, I had developed a few specialized state models [3], and even before that I knew that tuple spaces would be easy to integrate. These days, I'm especially fond of a simple, generic, and superbly robust state model as the 'default' primitive, based on keeping an unbounded logarithmic history [4]. But early in RDP's development, I struggled with the idea of RDP state and asked myself many of the questions you seem to be asking now. Keep it up. ;)

[1] http://awelonblue.wordpress.com/2013/03/23/ad-hoc-external-state-models/

[2] http://awelonblue.wordpress.com/2013/03/27/declarative-state-machines/

[3] http://awelonblue.wordpress.com/2011/12/02/animated-reactive-term-rewriting/

[4] http://awelonblue.wordpress.com/2012/08/20/exponential-decay-of-history/