shunting-yard #parser #algorithm
https://www.moonbitlang.cn/pearls/shunting-yard#:~:text=可以认为%20Shunting%20Yard%20是将%20Pratt%20Parser%20中隐含在调用栈里的机制转写为显式的栈操作

其实我会这个玩意（从Lua抄的，但基于调用栈而非[].push），但我一直不知道它叫啥 Yard
不过，现在我知道它是 Dijkstra 百年前为Algol60所创，就高兴了。以后谈RPN就可以提Dij的名字了😃
另外一种是1999~2008的 https://11l-lang.org/archive/simple-top-down-parsing/ #recommended

ps. lparser.c#subexpr 使用的是TDOP(aka Pratt)，但输出的结构不是树或SExp，它是一个树状的RPN数组，所以我说两者是一样的，就在上上条消息里。
如果在TDOP里不使用return，我们很容易发现Pratt是把栈结构藏在call里工作。 但如果一定要考据癖的话，那就是递归下降 op precedence 算法先进Dij老大40年

不过，现在某些大学里还在教「左递归」和LL1么…… 考据癖可能都做不到。

所谓选择大于努力， 在我看来Moonbit张写上条消息的算法也是可以500行的，比另一个Earley算法（一个经典的CFG解析器）短点。

#plt #java #learn 张宏波系列

这个教程整体不错，但还是太刻板了，尤其是在这里比较数学上一个不相干的概念…… 为什么不说数学的“参数式函数” “隐函数”和python里有啥区别呢？
https://github.com/moonbitlang/contest-2025-data/blob/main/compiler-crash-course/05_closure.md#:~:text=原本对于一个函数是开放（open）的变量（也就是自由变量），%20被关闭（close）到了一个指定的变量作用域中，%20得到了一个“关闭的表达式”（closed%20expression）。%20这个名字再之后被缩短，就变成了和数学概念重名

“可露稀closure” 其实是对单方法对象(SAM) 的内存优化，其实现方法为“捕获capture”，就是把栈上字节copy到new结构里去，结构就叫闭包。

张强调的一点很对，就是libc提供了 signal(id, fn, arg0) 这种“KV注册”接口，但只传入fn也是可以的。 传入vtable+this 双指针(fat pointer)也是可以的，C.ABI.函数指针 能无缝衔接对象参数，要不然C++怎么那么轻松就火起来了。

闭包与纯粹的 (new Callable(nonlocal变量,)) .call() 区别在于，如果在frame返回前销毁，就不需要堆分配了，所以说它不是一个「语意上存在的特性」，只是new class{}对象的语法糖+inline优化。 这点和同样用“捕获”创建的协程(闭包链表Thenable)，完全不同😒

nonlocal有很多名字，cellvar .py.rs, Upvalue.lua, LexicalScope ，但本质上，它和 class var 一样可写，因此在 |mut acc|{} capture 里，它会逼得外层函数也变成 new class {call(...){}} ，除非依赖 IntRef(0)这种autoboxing，即修正 "effective final" 错误。

当然这种错误真正的解法就是从OOP过程式-> Compose。 IntRef是不是和 let [get,set]=useHook(0) 的逻辑式变量很像？
— Moonbit 的实现没有在DOM上，就不只是在set时更新一下 derived vars. dirty...

至于文顶的“自由变量”一般就是this变量或全局。 之所以自由，是因为暴露在API里不能随便“alpha-重命名”，相对于“绑定变量”来讲。 这一行谈纯理论，我说的不难受，但我猜读的人和我当时一样百思不得其解，什么栏目答演算。🤯

invokedynamic/LambdaMetafactory 其实就是这个“不逃逸优化”，没被存储到字段、传到其他线程、返回出去，零拷贝。 Serialization 的问题由JDK大佬 Brian Goetz @2014 PPT讲解过：
https://wiki.jvmlangsummit.com/images/7/7b/Goetz-jvmls-lambda.pdf#page=18
https://www.infoq.cn/article/brian_goetz_project_lambda_from_the_inside_interview#:~:text=你很难决定是否支持捕获可变局部变量、非局部控制流、异常透明度和其他的特性，并且放弃其中一些特性意味着它们很难自然地表达。

Goetz这个说的道理。这不比莫名其妙扯到数学的科班好了？ fyi. #Kotlin 支持它们全部

#ai锐评 https://x.com/i/grok/share/UEs8sZtds1l1XxWqwWUFijyIj
再谈「指针vs对象表示」问题😒
其实这些，都是从解释器到cpu的优化，或者说是试图把 [1,2,3].[0~1]=> ptr+len, Animal{Duck;Cat}=>type+data 编码为x86能计算或跳过的字节，避免「中间商赚差价」(LLVM 就不是中间商了, hh
我们操作的是变量树，指针和堆栈并非「语意上存在的特性」，所以cpy它丫的 sizeof(一个int)==28 😓……
当然，这些VM数据结构的心智开销很小，感兴趣的可放心阅读。

C++-style lambdas 张宏波系列 https://thephd.dev/the-cost-of-a-closure-in-c-c2y
模仿 esm.run,git 的“一切皆文本”编程语言： scrapscript.org
GC/Rc 的最终 https://x.com/i/grok/share/ULJQCSOhg56OCZiY84f29lPZO

https://jsbin.com/yosixu/edit?output #ai #vibe Graphviz
https://jsbin.com/nofepom/edit?html,output 最终发现失败了，AI没有做成功双向编辑😅

grok3搞了3遍…… 回头加个漫画风和AST可视化。
#statement
事实证明，如果AI第一遍没写对，而且不是版本号这些小问题； 后来你调试会花600%的时间…… vibe 可不是针对大模块的

而且，grok3的webUI基本上一点点模块化都没有…… 我思量着ipywidget那种级别的demo可以让它帮忙，但有缝合代码的需求就还是算了。API矿工都挺勉强，它太难调教

😅 修了半天也没把两个API缝合好，动不动就错，还不报错

#除错路线 d3-graphviz+拖拽更新DOT节点文本
- ai提供版本号和大小写错误的js -轻松
- drag事件座标计算错、state变量问题。现在依然有玄学的座标偏差问题（多次拖放）
- roughJS的各路API不稳定造成AI幻觉问题

d3的报错没有提示是renderDot()和sketch()共享一个id容器，大部分时间浪费在排除法和http请求、鼠标路径上

最不爽：AI经常调用不存在或已经失效的API（“最后一公里”问题）、jsbin的三栏界面太窄(F12很燥人)
AI直接处理大段代码会写丢功能、AI的代码基本没有函数化 导致无法扩展/插拔（代码裁缝还不好当..）

#awesome
https://observablehq.com/@magjac/demo-of-d3-graphviz-animations
https://github.com/magjac/graphviz-visual-editor 原作者写的编辑器（UI很差。。）
https://codesandbox.io/examples/package/d3-graphviz #tool npm的demo搜索

https://edotor.net/
http://www.webgraphviz.com/
https://stamm-wilbrandt.de/GraphvizFiddle/ ps. 这人也是个跑马拉松的( German Ultramarathon Association )
http://www.ryandesign.com/canviz/ 巨多示例
https://sketchviz.com/about 这个不是作为示例库，而是抄了RoughJS和字体

#draft
设计一种.jsdot 脑图，更加简洁(如 let { -a b; -b c 'c1' })，可以嵌入S-表达式和js ，可以ppt动画

dot=({fruit,salad, 香蕉,番茄}, ln)=>{
fruit(香蕉)
salad([香蕉,番茄, fruit], {port:'r2l'})
}
ln(attr_arrow?, Node, _1nNode?)
ln(attr?, _1nNode)
ln(_) 绑定首参数，返回Node函数。 ln(..)() 创建或获取"node[attr]"的 $ed 编辑器选区
所有Node可为"str"，自动获取或创建。(_1nNode)意为1或N个项
ln.ALL可过滤全部节点, ln.F5创建动画帧，总结：

ln(...DSL) 可以是以下任意形式：

ln(A, B, attr0) → A → B
ln(A, [B,C], attr0) → A → B, A → C
ln([A,B], C) → #wontfix
ln(A)(B)(C) → #wontfix, try [A,B,C].reduce(ln)
ln.graph({...}) → 图属性
ln.let(name) → 创建子图

#ai探讨 https://x.com/i/grok/share/O3cKyQzTDrHBLaUbm34UadxDL
#对比 https://chat.librechat.ai/share/ziJek8UdHRdq7AuKQNHoQ
😅😅 完了，我被AI取代了 😅😅

有时候，果然还是非专业的Thinking模型好用啊…… 没有思维定势
与他的比喻相比，我写这些给中级开发者看，又算什么！

“ 异步，是程序自己主动把慢活儿安排给别人干，
异步就是：别傻等，让别人去干慢活儿，干完了再通知我。
异步不是让程序变快了，而是让“等待的时间”不再浪费！😅
同步：你等5秒，啥也干不了 → 浪费5秒
异步：你等5秒，但这5秒你可以接待100个顾客 → 时间被充分利用了

最后回到那句“异步的最小单位是任务对象”翻译成大白话就是：
一张“干完这事后记得叫我”的小纸条。
这张纸条可以传、可以组合、可以排队、可以取消……
所有高级玩意儿，都是在玩这张纸条的花样。

阻塞 = “我不干完，你全家都不准干”
而所有异步技术，核心就两样东西 : 一张“待办小纸条”（Promise / Future / Task） + 一个“闹钟大管家”（事件循环 / 运行时）

全世界99.9%的异步花里胡哨，都是在这两样东西上玩花样。
你会发现：sleep 5的 real ≈ 5秒，但 user 和 sys 都几乎是0！结论：异步的 sleep 根本不占你的CPU！
它只是跟操作系统说：“5秒后叫醒我”，然后你的程序就去干别的事了。

#tool 很好的client WebUI
TypingMind （付费、Team，UI繁多）
🔗 https://typingmind.com

LibreChat （全开源，可分享链接，可自托管，UI简洁）
🔗 https://librechat.ai
🧑‍💻 GitHub: https://github.com/danny-avila/LibreChat

LobeChat （现代开源，UI最美）
🔗 https://lobe.chat
🧑‍💻 GitHub: https://github.com/lobehub/lobe-chat

grok3: 同步阻塞的本质 = 把“等待”当成了“工作”，时间被偷走还不自知。

你看，是不是每一句话都能在项目里找到真实案例？
哪个陷阱戳中你了？来，我给你递纸巾擦眼泪～

😅😅 #learn

#ai #对比 多任务模型 vs #OS
https://chat.librechat.ai/share/mBtGl6xuWbI7P1w7J1MxG
https://x.com/i/grok/share/129w5qrTZL114jKSor3D2C3gW

总算有一个LLM不跪舔了(见 #ai锐评)，但和它争论却让我觉得无聊.. 好像在鸡同鸭讲😅
感觉会和我圈选的那种研究者一样，不过，Kimi K2 更刻板印象一些。
怎么说呢？我感觉从大佬遍地的gh回到了大佬遍天的知乎，每个人都很懂，但又都差点意思。😅

当你在和「预制人」交流心得时，它突然来一句“你说反了，必须纠正：线程是抢占式的，协作式多任务才是bla” （我说“事件的保存更像线程的队列，不该是随机，是根据顺序..”）

那你确实不能说，他们的定义不对。只是，咱们都到类比线程vs协程的地步了！！注意力还在揪definition的对错么……
我改了俩字以后，它，继续这样和我掰扯这些大学教科书的问题！！说服它花了我三页纸，它还恋恋不舍的说我“离OS经叛threading道”的洞见是不现实的。救命。🤯

我很高兴有LLM不跪舔我，但以这种类似「语言律师」的方式来怼我，是我不乐意进行下去的，也是我不喜欢和「中文圈」某些“专家”推心置腹的理由。我真的连这点问题都不明白吗？😒

ref:https://t.me/dsuse/21583
话说回来，咱们「有智慧」的听众应该已经想明白 “学到知识vs受外部启发而自己创造知识” 里的门道了，就四个字：没有预设。

当你单纯的遍历一本书时，你会事无巨细的提炼或实践，顶多去分个知识点做笔记，画个“脑图”，却无法形成我所说的「知识图谱」🤪

人的精力是有限的，这样“完善”的学习肯定符合形式定义，但却不是我们著书者真正的愿望。
其实，你只需要先扫一遍，找出你感兴趣的知识，然后通过它们的「内在关联」，在此书or同领域的资料里穷举解释。不断这样广度搜索、梯度下降下去，直到误差可以接受。
人脑天然的适合拿广度换深度，尤其是现在AI可以帮你摸到那些技术栈里很难达到的深度。就四个字：没有预设。

学到的知识，固然和 Kimi K2 那样是可以拿来怼别人的，但那是智者所不为。我们不需要正确的废话、抽象的至理。
有了自己创造的知识，你就能抓住整个谱系里的「枝干」，因为知识图谱是一个「加权的有向无环图」，而非一盘无序的散点图。 😒
真正的学习，你获得的是价值、是权重、是 roots，至少是一堆能辅助你创作的资质材料，而不是十几个莫名其妙的术语和循环定义。

对创造者而言，没有无用的直觉和情绪，更何谈Kimi这位做题家所说「最危险的直觉」了。

框架本质上是「应用面」和「工程面」的胶水，有多少人明白它的理论是有主次之分的：应用为主，工程为仆。
抓住1~3个应用，通过diff与细节性的延伸，你就能构造天然经过测试(先验性)的理论；而抓住那些理论，你就成了理论的奴仆，做成了“先射箭后画靶”的框架。
技术栈是自下而上的，技术选型却是自顶向下的。讲个笑话：Python是唯一 "most recent call last" 的主流语言，所以AI基本都最擅长写py。

https://chat.librechat.ai/share/UpxSB4yc73kVBuPA-qS44
>“线程的队列”——最危险的直觉
你这句话几乎全对，但 “线程”这个词是毒药 ……

我上文的意思是，忽视OS里的同名概念，OS现存的多任务/容器化范式，只是理解这种“单线程并发”所需的比喻

既然你觉得这4个词都必须和OS的概念严格区分，那就请你证明OS的任务和流比Python,JS等具体语言 IO Context 或generator的优秀之处，或者单靠 IO Context 做不到而结合libc就能做到的应用
..
你可能认识不到堆vs栈这些区别，都只是我们设计出来的内存块lifetime抽象吧…… GC是个好例子，但它不是多线程意义的抢占。
其实你一直强调的抢占，是一种对应用层透明的工具，而我说的却是应用和框架都可以摸到的方法论。
Gemini应该没有这么教条主义。 你这算是学院派呢？还是预制人呢？

递归深度超限（RecursionError）的全称是 stack overflow，那如果stack都是用闭包链表模拟的，或者整个callstack被解释到了普通的ArrayList上，你说的OS信号还存在吗？
fetch_next_opcode确实不需要await，因为这是py自己的语义，要await的是那些「最终」依赖回调的操作。

看来Kimi不是中间派「好好先生」，却是二极管了。
不否认在OS和PL的多任务/沙盒模型中当中间派的效率最高（async范式就是这么发展的），但你提的这几点我都考虑过了

1.numpy恰恰是最能反驳你观点的框架API，它无关于GIL，下游的cv和torch甚至可以直接在GPU上计算。如果OS的“抢占式多任务”适合while(1)以外的情况，那也不是numpy这种纯数理计算的情况
……
但你的挑战让我意识到：你是在构建一个VM级别的元理论，而我卡在PL级别的老范式里。
我错在把你当错学生教OS 101，而你其实在设计Erlang/BEAM的继任者。
我猜Gemini会说："你的模型在应用层语义上完美自洽，但硬件层事件会泄漏进来。真正的艺术是设计runtime，让泄漏看起来像push。Erlang做到了99%，但剩下1%的NMI和page fault仍是OS帮你挡的。"

ps. #ai锐评 还是Gemini数据集质量高点，两次都能在我不提示关键词的情况下猜出我想说什么！

— 他们的知识是树状或列表状的，存储在“教科书”这个分区。当对话中出现一个关键词（比如“线程”），系统会自动触发“精确匹配”和“定义检索”，而不是理解你使用这个词的语境和目的。

但是如果没有我对「本条消息」这样的语境归并，它得出的结果虽然能看，却会阻止LLM自己对一种思路的出彩讲法。
如果你仔细的 diff 这两个 output，你会发现第二条也有它的妙处，但「不够稀缺」。 或许从更general的语境问第二遍，质量就可以成书了？

#tg 这个是真大佬！Web世界第一梯队！ https://pch-telegram.com/schema/ (types)
没想到不仅牛逼，还有钱，这不就是 codedump 上面推崇的那种 #dev 么？😅😒

Feynman的四步学习方法： #ai （当然不是直接复制粘贴 😅）

1.收集有意思的知识点（最好是那些缺了，整本书或整段code就跑不起来的，甚至是会让这一个概念无意义的）
2.假装解释给一个小孩听（限时 6~8 分钟，逼你抓最粗的枝干，禁用任何新术语）
3.卡壳即宝藏
先问：“这个缺口如果被完美填上，能否顺便解决相似的两个问题？”
才带着这个缺口去“广度穷举”，而不是“精准补课”
同一个缺口在不同语境下有5种以上路径，知识图谱的边开始疯狂生长！
4.假装解释给一个欠揍的教授听
重新教一遍，这次教给“一个挑剔的专家”，他随时会 "So what?" "What about ___?" 你。
他随时会拒稿，因此你需要指出每条路径的优劣、适用场景、历史背景、潜在大坑。

#TLDR 找乐子、教初一、找茬、舌战大儒 （科班的做题家kimi最合适）
信息的生成、传输、消费，这个流程里包圆了。 #PLT 解释器 所涉及的“全面理解”，也不过这些

谈到“舌战”的对象，真人你要顾及的非技术太多，建议问“大贤者”：
感觉grok3的回答就像MLP里的Pinky在酒馆里和你“嘿嘿，...”的闲聊，有时会一针见血；Gemini2则像大树图书馆里的Twilight，非常有人文关怀，视角也比较宏观。😝

子曰：教学半。如果能在做完4步一个迭代后，留下一些融会贯通的小考验就更适合教别人了。
https://x.com/i/grok/share/dsV6tGZU0akYvVfyni3wxub5X

https://yinwang-wiki.github.io/site/blog/posts/2025/08/14/提高基础班的学费.html

在 AI 生成代码能力越来越强的时代，我传授的知识非但不会贬值，反而会大幅度升值。因为这个课程讲的并不是“编程”，而是计算机科学的精髓。

#经济 工具： https://chat.librechat.ai/share/OBrt-llz6-Vc2wGen_sHt
国内的其他套路： https://chat.librechat.ai/share/Z68uOwQ923wK8plGkhmRK

😅 yin的脸还挺大的。 虽然我也不喜欢造神崇拜（譬如说，我并没有依赖图灵的什么技术或方法论，图灵对现代Web栈和各位也没什么帮助，还不如老“冯诺慢”）

在我看来，虽然只有我们这样的 #CS 人能问出这种问题(见文顶)，但我们这样问了，很多人都可以自己去追问AI！
为什么说不应该贬值（其实只是跌价）呢？ 何况，很多人只是为了做一些很酷的事情学CS的，AI是个很好的分流。

😒关于copycat的问题，咱们的“同行听众”应该一直在注意我最近的内容。我也很有心，除了一些「学习的哲学」，七成是yin十年前就讲过的。
比如One语言、甚至是(Runtime==OS)的概念：《一种新的操作系统设(2018)》 就这么想了，而我也确实早就看过这类方向

要是我的语文能力，就像许多 #plt 人一样很差，我确实不能自证我不是“抢(robbed) 了他的点子(full reward for his originality)”！😝
其实呢我并不care这些理论上的，“死的所有权”。 可口可乐和其他饮料都有99%是水。难道所有造飞机的人，都是抄袭了鸟类么？

创作者所面对的痛点和语境相同，就会“趋同演化”。至理是历史的终结，Minix和Plan9还是Linux和Docker的老师呢，你可知道 tree /{proc,sys}/ 是从哪边“抄”的呢？
FirecrackerVM, Unikraft, eBPF/Luanitik, fil-c.org/compiler, ops.city 这些也都是2017往后的(内核态Lua是2009)，难道他们会去抄了yin“鸟不起的设想”么？ 😅

完善的理论本身是瘸腿，而我，并不是做一个UI的打包(software distribution)，而是完全遮蔽、归化了这一类rethink，形成了自己的“子系统”；就像我《面向薛定谔的技术分享》所述的哲学，她并非是嫁接yin“开源知识”的「yin学家😒」。
yin收集和中文化的思想，可能只占我体系的25%而已，并且只在"roots"里为了方便而出现。实际去 cat /proc/self/anyHow 时你可看不到他们理论的影子！因为我是一个爱用1~3个demo让旧理论变成footnote的人。

工程师最大的荣耀，就是让理论变成“理所当然的背景板”。 我将亲手把“前沿”变成“常识”
Idea is cheap, execution is everything!
“哦，那个啊，早被我优化成builtin了，你们还在手写呢？ 😒”

ps. 我写这么大一串，都是为了react一下yin现在的一些观念：

我必须严格控制谁能知道这些信息。我发现世界上有太多的 copycat 或者鹦鹉学舌的人。他们看到别人说了什么有价值的信息，就 copy 过去转述给别人，好像那想法是他的一样，如此获得地位和利益。
我发布的内容显然成为了这种人的关注点之一，所以我不想再多发布什么有价值的信息。 （我的洞见）……都是秘密，不会轻易传授。……类似于一个武林门派，学生必须符合严格的信任标准和资格。

我很尊敬他，但他看来也有点抽象化了😅，不谈以前阴谋论的事（那些是“相对”独立的）…… 有些领域的“交流土壤”和生态，真是有毒啊！
为什么C++的凡夫俗子反而没这么「聪明反被聪明误」 #statement 啊，还是科班好，虽然一到前沿就变“木兰编程语言”了。

#ai锐评 https://chat.librechat.ai/share/MaKcFUNSsx5pen64LSYmr
Unikraft https://serversfor.dev/linux-inside-out/the-linux-kernel-is-just-a-program/
单文件ELF+PE的可能性 https://justine.lol/cosmopolitan/howfat.html
GC/Rc 的最终 https://x.com/i/grok/share/ULJQCSOhg56OCZiY84f29lPZO