Unified State Expressions - Transitions (First Sketch) 
Published: 2020-11-13 13:32:50

--- series: Unified State Expressions ---

<!-- **Disclaimer** 
+ This is a sketch. While sketching is a valuable [Early Work](http://paulgraham.com/early.html) activity, it might blow up at any time.

## Intro
Below are some ideas for a notation appropriate for sketching and defining behavior of state machines that support [Total State](https://dev.to/rekreanto/towards-a-state-type-notation-for-total-state-8ej/edit).

A definition of State Behavior consists of one or more of behavior definitions. It is always mounted at its scope. THe scope is the larges path that is not affected by the transition being defined. I like to group all the reaction definitions by scope. I also like not to nest definitions of scope.

```ts
<behavior> = 
  <scope>
    <reaction>+
```
A reaction is the same as a named transition. The name serves one task: The UI can refer to it by name, and the machine can then find the closest transition and perform it. So:

```ts
<reaction> 
  = ! <name> : <reconstructor>? : <function residual>? 
<reconstructor> = <segment destructor>* -> <segment constructor>*
```

### The three parts of a raction
We see that a <reaction> consists of three parts: The name, the reconstructor and a function
The function takes care of any residual state from the deconstructor and returns residual state, if any, to add to the constructor.

### Optional parts of a reaction
There must be name. But both the reconstructor and the function are optional.

### Reconstructors and functions are conceptually the same
Under Total State, functions and reconstructors perform the same kind of work conceptually. They just use different computational methods in order to perform a transition: Computation by dispatch, or application respectively. That those two things can bee seen as one and the same thing conceptually is the essential property of Total State. (I introduced the idea of total state in an [earlier blog post](https://dev.to/rekreanto/towards-a-state-type-notation-for-total-state-8ej/edit)). -->

## Some examples:

The traffic light. Now with behavior

### Non-hierarchical Traffic Light

```ts

// State Machine Type
TrafficLight :> Green | Yellow | Red


// State Machine Reactions 
// Collapsed view
TrafficLight                   // scope
  ! NEXT                         // transition name

// State Machine Reactions
// expanded view
TrafficLight                   // scope
  ! NEXT : Green  -> Yellow      // reaction
  ! NEXT : Yellow -> Red         // reaction
  ! NEXT : Red    -> Green       // reaction


// State Machine Boundary Actions

TrafficLight
  :> 
  | Green  >> after(<duration>)( NEXT ) // boundary action
  | Yellow >> after(<duration>)( NEXT ) // boundary action
  | Red    >> after(<duration>)( NEXT ) // boundary action
 

```

### Counter

And the almost simplest counter from 15js:

```ts

// State Machine Type
Counter :> <int>


// State Machine Reactions
// collpased view
Counter                     // scope
  ! INCR                      // transition name
  ! RESET                     // transition name
  ! DECR                      // transition name

// State Machine Reactions
// expanded view
Counter                     // scope
  ! INCR  : : (  n ) => n + 1  // reaction
  ! RESET : : ( _n ) => 0      // reaction
  ! DECR  : : (  n ) => n - 1  // reaction

// Note that the reconstructor part is empty

```

### The Linksy Kitchen Timer

(It is the timer in the banner art above.)


```ts

// State Machine Type
LinksyKitchenTimer 
  :>
    | Setting :> ( <int min>, <int sec> )
    | Ticking :> ( <int sec> )
    | Paused  :> ( <int sec> )
    | Alarming.
```



```ts
// State Machine Reactions

LinksyKitchenTimer // scope
    ! START   : Setting  -> Ticking  : ( m, s ) => m*60 + s  // reaction
    ! PAUSE   : Ticking  -> Paused   : ( s ) => s      
    ! CANCEL  : Paused   -> Setting  : <history> // residual state is memoized
    ! RESTART : Paused   -> Ticking  : ( s ) => s
    ! OK      : Alarming -> Setting  : <history> // residual state is memoized
    ! TIC     : Ticking  -> Alarming

LinksyKitchenTimer :> Ticking  // scope
  ! TIC : : gt(0) ( s ) => s-1  // reaction

LinksyKitchenTimer :> Setting  // scope
    ! M10 : : ( m, s ) = ( m+10, s ) // reaction
    ! M5  : : ( m, s ) = ( m+ 5, s )
    ! M3  : : ( m, s ) = ( m+ 3, s )
    ! M1  : : ( m, s ) = ( m+ 1, s )
    ! S10 : : ( m, s ) = ( m, s+10 )
```



```ts
// State Machine Boundary Actions
LinksyKitchenTimer :> Ticking  // scope
  >> after( 1s )( TIC )          // boundary action

LinksyKitchenTimer :> Alarming  // scope
  >>  after( 30s )( OK )          // boundary action
  >> <start/stop sound>           // boundary action


```                      

## Separate definitions are preferred

The Behavior part seems to be 3-10 times larger than the State Type definitions if measured in SLOC. That, I think is a good argument for giving the type information separately; it might otherwise be less readable and less useful.