在阅读了 Miro Samek 的优秀著作《Practical UML Statecharts in C/C++》之后，我迫不及待地想尝试一下。最近，我开始自学 Haskell 和函数式编程。
\n在我关于 Haskell 的书刚读了几章后，我就突然意识到状态图可能很困难，甚至与 Haskell 的风格背道而驰。毕竟，创建无状态程序需要付出巨大的努力，或者至少将代码的所有不纯部分与纯代码部分很好地分开。
\n当我在网上搜索“Haskell”结合“statechart”时，我几乎什么也没找到！这激起了我的好奇心。毕竟，Haskell 是一种相当古老的通用编程语言。怎么可能\n似乎几乎没有与状态图相关的活动？
\nHaskell 的 Reddit 子主题“ haskeller 对状态图的思考”中提出了几种可能的解释，我希望我的简短摘录不会扭曲任何作者的观点：
\n/\xe2\x80\xa6/ Haskell 社区总体上在 UI 开发方面不是很活跃 /\xe2\x80\xa6/
\n/\xe2\x80\xa6/ 状态图的缺点是它们提供的所有灵活性\n使得模型检查（以及基于模型的\n测试）变得更加困难。/\xe2\x80\xa6/
\n/\xe2\x80\xa6/ 状态机是状态和转换规则的集合。但由于实现状态是多余的，您可以单独使用转换规则，这些规则被整齐地表示为（相互递归的）函数族。/\xe2\x80\xa6/ 但 Haskell 不受此限制，因此显式实现状态机通常是多余的。
\nHense（原文如此！），作为一名 Haskeller，我大多数时候并不真正需要显式状态机。作为一等公民和 TCO 的功能，在最好的情况下是一个实施细节，在最坏的情况下是不需要的。/\xe2\x80\xa6/
\nA。/\xe2\x80\xa6/ 在 Haskell 生态系统中，你可能会更幸运地使用“转换系统”、“演员模型”或“状态转换器”等搜索词。/\xe2\x80\xa6/
\nb. /\xe2\x80\xa6/ 函数反应式编程 (FRP) 和箭头是 Haskell 中\n实现信号流的方法。/\xe2\x80\xa6/
\nC。/\xe2\x80\xa6/ State monad 转换器可以对此进行建模。如果中间步骤中有\n外部信号，则可以\n将其嵌入\n延续 monad 中。/\xe2\x80\xa6/
\n我允许自己解释一下，并对此进行评论：
\n