Unified State Expressions -  State (First Sketch)
Published: 2020-11-11 10:26:40

--- series: Unified State Expressions ---


<!--**Disclaimer** 
This is a sketch. While sketching is a valuable Early Work activity, it might blow up at any time.

**Terminology** I introduce some new vocabulary as I find appropriate. This makes it much easier to talk about concepts that are similar but different.

**Reading Guide** Just skip all text and scroll down to the examples.


## TL;DR
As useful as Visual formalisms are, sometimes code is more convenient. State Type Notation (STN) aims to do for State Machine Programming what type annotations does for Haskell, TypeScript and similar languages: When you have nailed the type, the rest is usually straightforward.

## The diff from ADT
STN takes inspiration from Algebraic Data Types (ADT) as denoted in Haskell. The diff:
  + STN adds a construct for subtyping/refinement
  + STN allows for inline expansion of Nodes/States

## The diff from traditional Statecharts
STN works for Total State, that is a superset of Statechart State. The quantitative/extended state is coded into the (leaves of the) State Type. This is what ADTs has been doing all the time, so no biggie. The advantages of the unifies approach is that:
+ The shape of the data is always know, so nulls kan be expelled from the formalism.
+ Full modularity is supported, so that all machines on a state can have their part of a Global, Unified, Distributed State, often referred to as "Essential State". Essential State is what is needed to resume the app/ui.
+ The rendering of a website can be defined solely as a render function that dispatches on the total state (preferably with access to the state type and the data source).
+ Total State and thus STN is more permissive in that is also allows Alternative states to have their own branches. Just as ADT, and the relational data model, by the way. In traditional Statecharts, such as SCXML, a state can only be either "and-state" or "or-state".
 
## Intro
A Statechart is a visual representation of the possible states and transitions of a Hierarchical state machine. State Type Notation is a textual format for denoting all possible states (not the transitions).

At the moment, it is not clear if STN is also useful for  denoting the state type of traditional Statecharts.
  
### Total State
STN is designed to support total state. Total State is a superset of Statechart State, that unifies Qualitative State and Quantitative State into one common state, putting the data as leaf nodes, where the shape of the data is always known. 
  
### Null
Null is the incarnation of technical debt in its most concentrated form. It is the mark of data whose shape information is missing. Null is not a valid value of Total state. Non-existence of a branch is represented by the omission of that branch.   
  -->

## Constructs
  ```js 
  `alt`              : e.g. `Red`, `Green`, `Yellow`, `Guest`, `LoggedIn`, `About`, `Welcome`
  `branch`           : e.g. `@user`, `@page`
  `or`               : `|`   or `---` e.g. `Red` | `Green` | `Yellow`
  `branch-expand`    : `:`   e.g. `@user: Guest`, `@page: About`
  `sub-expand`       : `:>`  e.g. `Red` :> `Walking` | `Waiting`
  `optional-sub`     : `:>`  e.g. EditEvents :>?
                                             | SelectedEvent <id>
                                             | CreatedEvent <id>
  `atomic-marker`    : `.`   e.g. `Green.`, `Yellow`. // optional
  `composite-marker` : `...` e.g. `Red...` // optional
  `agnostic-view`    : // the omission of atomic/composite marker
  `system-types`     : `<...>`,  such as <int>, <string>, <date>
  ```
  -- Alternatives (or-states) or Branches (and-states) is per default shown collapsed. The next step, the refinement/branch value, can be shown using the expand-constructs `:>` or `:`. Atomic states, marked per a trailing dot `.` cannot be expanded.
<!--
  -- Is a notation for distinguishing btw Leaf/Atomic States and Refined states needed?
-->

## Sample STN Notation for some Traditional Toy State Machine Examples

### TrafficLight from xstate.js.org

  [Example source](https://xstate.js.org/docs/guides/hierarchical.html)

  ```js
 
  // agnostiv view (we don't express whether or not there are refined states)
  TrafficLight :> Green | Yellow | Red

 
  // Collapsed explicit view (denotes atomic/compsed nature of states)
  TrafficLight :> 
               | Green.
               | Yellow.
               | Red... // can be expanded


  TrafficLight :> 
               | Green. 
               | Yellow.
               | Red :> // expanded view of Red
                     | Walking.
                     | Waiting.
                     | Stopped.
                     | Blinking.

  ```


### Counter toy app from 7GUIs

[Example source](https://eugenkiss.github.io/7guis/tasks#counter)

```ts

Counter :> <int>

```

### TempConv toy app from 7GUIs

[Example source](https://eugenkiss.github.io/7guis/tasks#temp)

```ts
// agnostic view
TempConv :> F2C | C2F

// expanded view

TempConv :> 
         | F2C >: <string Fahrenheit>
         | C2F >: <string Celcius>

// this is all the essential state needed to restore the app to its state
// the source number as well as the converted number are derived from the input string


```

### Sample small website GrowersAssociationSite (GA_Site)

Source: This is part of a (toy) site I'm working on as part of my web design educaton.

```ts

// collapsed view
GA_Site 
  @lang
  @user
  @page



// expanded view
GA_Site 
  @lang : sv | en | ja | eo
  @user : Guest | LoggedIn <string UserName>
  @page : About 
        | Join 
        | Calendar :> 
                   | BrowseEvents
                   | EditEvents :>?
                                | SelectedEvent <id>
                                | CreatedEvent <id>
                                | UpdatedEvent  <id> 
                                | DeletedEvent  [ <id>, <string date>, <string descr> ]
                                | UndidDeletion <id>




```