大家应该没听说过 .c 编译产生的 .o ELF 是什么结构。好，我们看看：

`file /lib/libcurl.so*`
/lib/libcurl.so.4.8.0: ELF 64-bit LSB shared object, dynamically linked
`readelf -Sh $_ |tbl-hl 'text=代码;rodata=字面量;bss=mut全局;data =val全局;dynsym=dlopen函数链接;'`

注意， PROGBITS 代表这一个Segment是系统级单实例的，仅存的 .bss:NOBITS 会在库构造器里'\x00' malloc，剩下的都被C虚拟机无视，只用于 gcc,gdb,pref 除错。
AI展开： https://x.com/i/grok/share/jyixQkW0SNiIKtpGboy5LFUsG#:~:text=Linux%20动态%20PIE%20进程执行的绝对核心，
中科大真人快打： https://lug.ustc.edu.cn/wiki/user/boj/linkers-and-loaders/#38-目标文件中的数据结构

#tool 高亮注释
`tbl-hl() { sed -E "$(sed -E 's|([^=]+)=([^;]*);|s/\1/\x1b[38;5;208m\1\x1b[0m(\2)/g;|g;' <<<$1)"; `

https://gitee.com/HW-PLLab/pllab_slides/raw/dev/WechatOfficialAccSlides/20221123-EffectHandlers从函数式编程到系统级语言-by-DanGhica.pdf#page=8
https://github.com/cangjielanguage/cangjie_stdx/blob/a7c43d44381a995262ac93ba56dce66090613269/doc/libs_stdx/effect/effect_package_overview.md

Algebraic Effects(AEff) 是最近纯函数式PFer的动向，用于替代各种Monad。这其实是PF对“易变现实”的很大让步了
就像不理解 “伪递归=改参跳到def开头重来”，PF非常在意“堆变量不纯，栈变量不纯，参数变就纯”的无聊形式，于是就有了 `{IO,State,Random} Monad` 这些“纯粹的参数”，组合出Monad jQuery式的调用链，就叫“do语句块”

`State(0).fmap(u=>u+1)` 其实就是 `Var(0).then(u=>u+1)` ，因为u+1那块可以调用另一个“广义Promise”，就有了 `flatMap(async(u)=>u+1)` ，这就是染色问题（没错，这正是 #Haskell Logo >>= ！）
flatMap的语意在List上很怪异，但对await这种Effect是必要的，记住：这个“盒子”不能拿 Var(wtf).v ，它只能 Var(wtf).then(cps) ，那么cps返回Var就会扰乱后续链！当然Monad有一套“Algebra而惧吧”的文字游戏（比如foldMap），这里只提applicable。

与强行拿call回调串联顺序，在语意层去手写interpreter里“求值序语法”的单子相比，AEff 更是典中典。 不过我在这里，却是要欲抑先扬的赞同AEff的4个爽点。

我喜欢把 Algebraic Effects(AEff) 函数叫做“袋鼠效应器”。错误、系统调用、localStorage等“感受器”被她放在育儿袋外，代数跳出袋子，感受器就【择机】把它放回去：
- 异常的冒泡、重抛或替换，类似Rust受检的Result<T,Err>
- “请求局部”的可变量容器，就像隔离的 Arena,localStorage,Worker全局 ，这样PFer就不会受“参数变才纯”的限制
- 单例工具的参数注入，比如“进程”的pwd，fetch的登录头
- 异步(syscall)！求值栈转回调链表，才能够做 sleep() 和 evpoll/queue 等“内核态操作”

异常异步相耦合，“IO结果注入”和可变容器相耦合，可以说很优雅的确定了报错与IO请求的“范畴”。
袋鼠妈妈，就是evloop，那感受器自然是线程了！catch时她停止resume，并且waitUntil池空的话，进程自然退出。

虽然用 auto await + implicit_arg(getters) 很容易breakdown AEff的概念，但它的本质是在于【可观测性】：在于静态确定“卡线程的调用”卡多久，依赖fs还是db，而非模拟(Promise.catch)。
AEff实现“参数变才纯”时，就比Monad轻量了许多： 别忘了var.flatMap(Var内)可以有then以外的键。 不过这种文字游戏对practical是白费脑力。

上面说欲抑先扬，那表扬完该批评了：AEff 中看不中用！
相对于DOM/Java“漏洞百出”的IO限界和样式值注入，Monad还不严谨吗？ 尽信书不如无书，尽受检不如不检。一个白屏是100%不会抛错的，这就是“干净”的价格。

我自己用我自己的异常和异步范式，实现那“4个爽点”
Result有另一种实现：所有值，包括0都是truthy。null,Error和NaN是falsey。只允许object键的值是null，而访问Error的任何键都会throw。

在这种模式下，为Result提供冒泡、捕获替换的最好方法，不是AEff的“自动await”，而是nulley链(?. 和 ??)，比如 txt=readSync('_404')? ，再加上“异步函数名”的约定，比如 read?('_404')? ，这些可以预处理实现，缺点是没有AE的默认值注入那么“自由”

至于可变状态，我使用类似Hooks的 n=inHole(0); n1=n.As(x=>x+1); n.As(233); assertEq(n1.v, 234) ，这个模式显然兼容Promise，As就等效Thenable。

---
有人告诉我可以直接在AEff语言上实现 read()?错处和“函数名?异步”，从而在架构上利用AEff，业务上却使用nulley链。这忽视了“async是否天然就该标明”的争议点。

AEff，或许是对系统调用的极佳抽象，也可以“插入”传统的OOP异常里。这就像closure变量不等于this变量，函数值与dict原型链，【正交】构成了对所有数据和操作的“Composer”。

但我认为，closure和SAM对象的协调性是特例，AEff和nulley链只能择一而从：AEff说到底还是 auto await + implicit_arg(getters) 的赠品，错处的一致性，不可能超过由链提供的默认值或rethrow操作！
AEff的赢面，是用函数签名【静态】确定线程的await，甚至能区分noreturn抛出vs捕获回调链表的优化，就像closure能unbox掉不泄露的SAM对象或纯const的cellvar。
但隐晦和省事，在工程上未必是好事，尤其是定义与使用处都不一致的AEff。

在应用编程时，几乎没人会根据Error子类去注入default，因为那天然是caller的职责，并且，其实 IO 是非常有限的！fetch() 或FileReader的caller“应该”有几层？

async到处乱窜，是因为UIUX没有切换到基于信号变量的 compose API ，和React恼人的useMemo一个道理。 本来是“setter续延”的粒度不够细导致的，AEff再去模糊界限，是对timing语意的忽视。
另一方面，AEff的函数签名过于复杂。异常和“系统调用”应该静态检查，但分的太细就是“屎上雕花”。我从没见过隔着两层caller还能针对性的fallback，而95%的App都以C的那种tag+msg处理异常。

仅仅是为了“async到处乱窜”和“参数变才纯”扩充结构化异常，看上去很值，其实并没有认识到“异步操作”的局限，也掩盖了catch{}本身的糅杂性；这就像Monad这个丑陋的“栈上Heap” hack，是在将错就错。Monad也是一个到处乱窜的“动态域”，do语句块可把它驯服了？
AEff 可以轻松实现“结构化并发”（协程的批量等待与撤回/close），看上去也很牛，但“异步的祖师”，DOM fetch() 用的却是信号变量，这不足以指出班门弄斧的“袋鼠笑话”吗？
ES6花了10年把你从for(x)带到forEach(x=>)，“结构化”的学霸又把你带回去了，那你打算怎么用“结构化并发”写一个IDM的暂停重下呢？
DOM或许像没有兼容问题的一体机，但它的思想是纯粹的。我们需要的是 Worker<->Promise&Signal、普通计算<->异步IO管线 这样清晰的解耦，而不是半吊子的“大同”！

json本身是一个非常简单的文档树编程语言，但它成了事实上的标准。
Lisp可以称为语言里的语言，因为它只有变量查找和函数查找不可重定义（虽然很多Lisp不支持调用链）（这里的method lookup是指闭包和同构于闭包的宏）

理念意义上，《黑客与画家》的作者PG的“百年语言”是对的，因为它既不是SKI这种对bf和dup/swap的模拟，也不是Scala这种类似于C++的美与丑大杂烩，也不是晦涩的PFP语言，而是复用和状态转移的箭头本身。

PG加上了Lisp匮乏的非链表式集合与位置语法，简化了let-in等纯函数傲慢，所以虽然Arc被yin评价为“退步都算不上”，还是能从反面启发我们： Worse is Better, just like Markdowns.

G3: Java 引入 for-each，它是把“迭代器模式”固化成了语法；当 Python 引入 decorator，它是把“修饰器模式”固化成了语法。
这对初学者是好事（Worse is Better），但对追求终极“理”的人来说，这是语言设计者把太多的石膏涂在了核心逻辑上，导致我们看不见下面的“肌肉线条”。

Lisp（特别是 Scheme）之所以被称为“百年语言” “语言中的语言”，是因为它拒绝固化。它只给你 lambda 和 macro，剩下的你自己造。

而你心中理想的“百年语言”，其实是在寻求一种黄金平衡：
它不完全像 Lisp 那样拒绝一切固化（太累），也不像 Java 那样固化一切（太僵）。
它固化那些最符合人类直觉的模式（如 Markdown 的排版，JSON 的层级，Kotlin 的简写），而保留核心的流动性。

所谓的《屠龙术》，最终不过是：看山是山，看数据是数据。不再有“纯”和组合子，别无他物。

...你觉得，调用链、惰性求值（autoclosure）、cond 不是核心语法吗

这里的method lookup是指闭包和同构于闭包的宏，函数作为值是核心，所以减不掉

if剪枝和call的栈或回调链表语义还是要保留的，确实存在递归的需求，代码是要运行的
OO模块化的调用链,nullsafe 需要打开函数查找模式来添加。

cond,惰性求值,pmatch 这些确实可以用宏


这里存在有争议的两项：过度工程的 effect, 基线和状态转移不明确的 loop
IO effects 本质上是一种高效的 yield tag+tuple （await的实现证明了这点），因为它能在return前让结果可见。 如果把OS的syscall也视为yield，这个定义就是一致的。也就是说IO并没有那么“不纯”

loop 的卡死（阻塞时的死锁）是需要effects的一个理由，tailrec 是对基线+转移模型的严肃化，但我觉得明确的 time slice 和event signals(取代 poll) 更完备。

其实你知道我说的 递归固定点（运行时支持） 是对调用层叠的实现，那么对堆也应该定义下，不过Lisp没有区分值vs地址引用

但是可变性又成了新的“引用”。虽然类型化区分二者的收益不大（不同的app可能完全偏向值/容器引用之一，Int本身也不一定是“autoboxing primitive”），struct inter (类似于 str intern) 又是负收益（不是万物皆有 Eq trait-比如闭包），但一个正确的语言还是要区分值类型，哪怕是为了写独占(unique_ptr)

结构性共享?

哦，我设想的一种共享不是直接的内存池，而是模拟def(mutArg) -> oldTree
这样虽然每次使用都要先把mutArg应用为保存好的tuple，但是非常明确的，就像ThreadLocal

这个方案特别优雅，学习负担低，但是也不适合“1次调用”以外的情况——Clojure 持久化结构 是真的创建了共享，而我是依赖于调用栈，显式重放

其实…… 变量树的问题是被高估的，因为一个优秀的程序员不会被GC/malloc的性能卡住，问题在于语言能否信任他们的学习能力。

手动重放变量树里的hole，其他项尽量深不可变（phased lifecycle）
这种模式很好。它和Java的“元组泛型<A,B,C..>” 数据很像，推导后的元组泛型就是不可变的

我在考虑更好的模式

区分“僵化语言”和“活体语言”的关键点——**“点号（.）”的解释权归谁？**

* **在 Java/C++ 里**：`a.b()` 的含义通过编译器写死。如果 `a` 是 null，JVM 抛出 NPE，你无法干预。
* **在理想语言里**：`a.b()` 仅仅是一个语法糖，它在底层被翻译成 `send(a, :b)` 或者 `lookup(a, :b).call()`。

如果我们**固化**了“发送消息”这个动作，但**开放**了“如何响应消息”的逻辑（Method Lookup），奇迹就发生了：
1. **NullSafe**：你可以定义一个规则：如果 `a` 是 Null，`lookup(a, :b)` 就返回一个“什么也不做的替身（NilObject）”，而不是报错。NullSafe 变成了库的行为，而不是编译器的特权。
2. **Proxy/AOP**：你可以轻易拦截调用链，做权限检查或日志。
3. **动态转发**：类似 Ruby 的 `method_missing` 或 Lua 的 `__index`。
https://chat.librechat.ai/share/Lh_1H_JhfmTxW2juTln2f
https://x.com/i/grok/share/0w2xy2ztSjghopoD9KRjA7rOp 这俩都很优秀啊……

v8在光追上比JSC坏点，代码也多不少（但可能是没有模板单态化 所以bin反小10M）。PrimJS是字节的QuickJS，MuJS是0.4M bin
JVM自带的Nashron和Mz的Rhino（用AutoJS的应该不陌生），Graal惜败V8
并不是 Googlers 不如水果，raytrace 是“重计算、轻对象变异”的场景，可能适合WebGPU的实现。V8 自带了巨大的 init Heap Snapshot 还是比JSC小啊

很容易看见，pypy,jsjs 元循环“硬特匹蕊特”本质上就是把 try{}catch{}finally{} 等等硬流控逻辑外提为对VarTree的深先重写，
从而将 {..} 转写为 (e.try).evalIn((env))，其中.try和 runtime env 可以组合与替换。 如果把局部分配编号化，把跳转固定化为goto，你就可以得到JVM的汇编模板解释器
元循环本质是在做 round-tripping，才很容易找到这个「编号元组化 vs Str和层叠查找」的符号表差异，以及基于offset而非调用栈的流控，这就是唯一两个语义差别了——它是可组合性的骨架

思考：为什么不是所有bytecode解释器都能“免费获得”汇编模板解释器？ 因为jmp的语义没有固定到已生成（或backpatch）的opcode
而 tree walker 和 tailcall interpreter 间的性能差异如出一辙。从广义看，eval(if(q)A:B) 和 computed goto vm_iseq[q?A:B]; continue.. 都只是一种跳转，后者少了stack开销（因为更紧凑），这也是tailcall字节码解释器的缓存友好
#FP 对尾递归的追求并非自讨没趣，如果宿主语言支持完美的 TCO，理论上“函数调用的解释器”和“Goto 的解释器”在机器码层面是可以等价的（Scheme 解释器常利用这一点）
btw. 另外，这里有两个全靠 InvokeDynamic, Partial Eval的免费编译器？ 它们的查找和跳转是怎么实现的呢？