🤔 以后我会把 unification 翻译为『一致化』而不是『归一化』吧
至于不同的词性我不想多说，举个例子，unification type inference 是『一致化类型推导』、make unify 是『令_一致化』
理由是，如 a+1=b，一致化暗含了两者本来相等“一致”，但归一化给人感觉像是 a+1 本来不等 b，只是 apply 了这个操作以后才相等了

对 a+1=b 的一致化只可能成功或失败而没有结果，但有需要的副作用：求得 a+1=b 时 a 的值，使得等式成立的值，这才是 unify 最基本的操作

#life 刚才俩看婚配选秀节目，一个是啥象公司的，有点好看

秘技・智商量化

这个例子可以联想出，
中国(subject)、厕所(object)
是相对的 subject 重要呢，还是 object 更重要呢…… 如果 object 是 subject 的一部分，那么 会不会倾向朝 subject 这个更大的方向想呢……

还有一些不常见但很妥帖的联想，先逐一枚举某个 a 的所有属类，再取得其中和 b 有联系的部分，再选取时间/位置上最接近的事物……

但是所谓的智商 真的就能代表应对各种实际问题的能力吗？

CodeHz 熟不熟悉 对子程序作用域的实现
以及对 by-value, by-name, by-need 三种求值模型的实现

真的需要 by-name 参数求值方式吗？闭包的实现有什么注意点吗？

如果只是实现解释器不带虚拟机，会不会显得太幼稚？
如果只有到高级语言的后端连作用域都不处理，会不会显得太前端？
如果没有实现 native 或者 bytecode 后端，是不是会显得不够好看呢

啊，这么说蛮有道理的
可是 对求值来说 顺序也是最终程序要编码实现的一种语义吧
记得 LLVM IR 里 SSA，虽然重要的是“内联”表示 val ref，但其实有副作用的话是不能不顾赋值顺序的

by-name 实现起来不好吧，都得传 block 进去，把那东西内联……
block closure 的实现有什么注意点呢

这个是常见实现
直接 clone 一个，然后 update merge keys

就是说 by-value 调用前优先顺序求值？
function wtf() {
if [ a = 0 ]; $1
else; $0
}

不存在子程序作用域啊…… 子程序离开了之后还是存在、递归的话就会冲突

原来 shell 都是 call-by-name 的，直接传递代码字符串的引用，而且没局部作用域、没闭包

$1 $2 $3 是局部变量吗？
还是我 some_fn a b c 的时候赋值的全局变量呢？

想起了 Ruby 里的 lexical_specialvars

不能赋值啊……

是一个 shell 概念上会定义的东西啊…… 对名字的抽象语义

xs

你觉得就解析器而言，是带 tokenizer 的好些还是 scannerless parsing 好些？ 🤔

我听人说 parsing 和 type inference 的本质都是 unification，你怎么看？

可是 scannerless parsing 更符合直觉，如果加上 tokenizer 的话要维护两个级别的输入流

tokenizer 的结果往往不好看，而且即便是类似 coroutine 一样的 nextToken() Sequence 模式，tokenizer 也会造成一些 SourceLocation 对象的资源浪费
从性能的角度，tokenizer 更容易做优化吗？