#os #fp #statement
从脚本单步，组合到程序，本来就可以实现为调用堆叠、回调链表 两种形式，和浏览器的历史栈一样，都是记得结果赋值到哪，组合数据结构 来解耦程序的“菜系”，形成API，提高表达力。

如果说 inc (Box n)=(Box n+1) 就是纯函数，而 box -inc; 隐藏了致命细节，这就是因小失大。FP不过是把赋值写入了栈上，还模糊了改写时复制/useMemo的时机。修语法=修语意？

js流行的 Reactive 不过是把 let [A,B]=match_XML(..) 从栈上拷下来，支持自定解构脚本，不是什么发明。类似这样狭窄的理解能力在做infra/做原理的人里比比皆是。

为什么要区分调用和回调？ 只是Stack内存和变量树的减枝,GC 绑定得太深，必须用 new SAM_POJO(..) 把 vars(let-locals+栈上临时cell) 甚至回调的行号(yield)，外提为this，能跨越的范围才足够广，
比如能 JSON.load/dump，能放在IO轮询队列(甚至SQL)里，而不必元编程。 闭包和 Java 的 int vs Integer 装箱，完全一样。

例如把while(1)预处理成隔1毫秒yield一次的那种，和stdio行缓冲一个样，就要"pid"这个this了。毕竟……Linux-ELF就是个段错误版的.class，还不如WebAPI和esp32生态诚实。


因此，区分模块、功能点所必须的vars()树是绑定局部、参数、this、inline #def、模块KV/全局KV表？ 都没有意义，前三者本来就是封装简化的核心，所以()=>和enum{Ok(), Err()}可能是对的，跨越了堆栈，没有boilerplates，但也可能是难以二次开发、层叠的元凶。

唯一的方法是从语意解构APIs，诚实的描述用户和开发者需要的模型，而不是生搬硬套拉丁文。

例如，能够热迁移一个pid，像老式游戏机一样存读档的 CRIU Docker 和真正的操作系统plan9，就很理所当然。 是硬件和二进制在拖后腿

那群家伙至今也不想承认没人真正在乎 i32 i64 的极值是多大，u32比i32好多少，对，就是搞出千年虫的那群nerd。为啥不叫 byte4 byte8 char4 好了？ who cares?

或许这才是OOP和FP间选不出最优的最大原因：人群不同。