[<<][rtl][>>][..]
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
  in.

- 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?

http://hackage.haskell.org/package/quickcheck-state-machine




[Reply][About]
[<<][rtl][>>][..]