Notes on Implementing Reactive Version of Wallingford
December 2015

PROCESSES

A central concept is a Process (or WallyProcess or Actor or
FrameOfReference). 

Each process has its own clock.  There isn't any default behavior of the
clock.  It could be constrained to be equal to the system clock, to run at
half the rate of the system clock, to be delayed by 2 seconds from the
system clock, to be sync'd with the clock of another process, and so on.

The clock may advance:
 - due to an internal timer (e.g., clocked flipper example)
 - due to a notification of some event its watching for (e.g., button click) 
 - because it's observed



An observer can watch a process - to do this, it sends a 'watch' message to
the process, and gets back an indication of how to handle this.  Right now
the options are:
  - continuous (the process is changing continuously, so you need to sample)
  - discrete (the process is changing in discrete steps; it will notify you
    of any change)
  - static (not changing)

Not sure we need the static/discrete distinction.

The watched process can also notify the observer it is changing its status
(e.g. from discrete to continuous).

An observer can also 'unwatch' a process.


EXAMPLES

PULSER.  Has its own clock.  (At any rate it needs to refer to a clock, and
its probably better if it has its own.  Then we could have pulsers with
differently running clocks.)  The pulser tells the viewer it varies
continuously; it only updates when observed by the viewer.

FLIPPER.  This is a circle that changes from black to red and back each
time the mouse button is pressed.  When the 'when' macro is evaluated, the
flipper tells the system that it wants to watch for button presses.  When
the viewer says it's watching, the flipper says that it changes discretely,
and notifies the viewer when the display needs to be refreshed.  Then in
operation, if the button is pressed, the system notifies the flipper, which
re-establishes the constraints in the body of the 'when'.  This in turn
will cause the flipper to notify the view that it has changed.  The flipper
has a clock, and I guess it advances it whenever it changes state, although
it doesn't actually use time.

CLOCKED FLIPPER.  This is a circle that changes from black to red and back
every two seconds.  This uses a 'while' nested in a 'when'.  When the
'when' macro is evaluated, it sets up an internal timer that goes off after
two seconds (causing the clocked flipper's time to advance).  When the
viewer says it's watching, the flipper says that it changes discretely, and
notifies the viewer when the display needs to be refreshed.

FALLING BALL.  Has its own clock.  It changes continuously.  The clock
advances and position changes when the viewer observes it.

BOUNCING BALL.  Has its own clock.  It changes continuously.  The clock
advances and position changes when the viewer observes it or when it hits a
wall.

DRAGGING.  This is a circle that follows the mouse while the button is
down.  This is implemented using a 'while' macro.  Initially it changes
discretely.  In this state the observer just waits until notified.  When
the button is held down it changes its status to 'continuous'.  In this
state the observer keeps updating, either using its own clock or if the
circle says it has changed back to 'discrete'.

DRAG FOR 2 SECONDS.  This is a circle that follows the mouse for 2 seconds
after a button push.  This is a nested construct (macro? temporal
constraint?).  The outer one is a 'when', the inner one is a 'while'.


DRAG AND DROP. .....



VIEWS

What is a view?

a) a separate object, kept in sync with thing it is viewing using a constraint
b) a message sent to the object that either returns the view or has some
   side effect.  If it returns a view, then this is like a).  Side effect
   seems unclean.

END USER PROGRAMMING

blocks?