Wed Aug 14 18:47:20 EDT 2019
stat should be local in both place and time
- use a lot of encapsulation: compose state machines based on the
protocols they receive and produce, not about what state they are
- keep state short-lived. i.e. reset to known state often and
predictably. ( rationale: long-lived state "residue" is what makes
things hard to test. )
These two rules already eliminate a lot of issues. They treat state
as an implementation detail that is not observable at higher protocol
units. ( Cfr. implementing FP lang in IP lang. )
Try to design in protocols, data flow. Might be specific to my
applications, but it seems to be the way to go. Protocol oriented
programming: a protocol and the state machine that parses / generates
it are two sides of the same coin.
Protocols are state machine traces.
Maybe related: Quviq quickcheck state machine analysis?
Is there a Haskell variant that can do state machines?