Each language version is independently generated for its own context, not a direct translation.

这篇文章提出了一种全新的编程思维模型，叫做**“继承演算”（Inheritance Calculus）**。

为了让你轻松理解，我们可以把现有的编程世界想象成两个不同的国家，而这篇文章介绍了一种能同时统治这两个国家的“超级语言”。

1. 两个旧世界的困境

想象一下，现在的编程主要有两种流派：

函数式王国（ $\lambda$ -演算）： 这里的人像魔术师。他们擅长用“魔法咒语”（函数）把东西变来变去。
- 优点： 逻辑极其严密，能处理极其复杂的计算。
- 缺点： 一旦涉及到“状态”或“修改”，魔术师们就头疼了。而且，如果你想给一个已经做好的魔法道具加新功能，往往得重写整个咒语。
配置/声明式王国（如 NixOS, JSON）： 这里的人像装修设计师。他们不写咒语，而是画图纸（配置文件）。他们通过“合并图纸”来构建系统。
- 优点： 非常适合管理复杂的系统（比如整个操作系统的配置），改一个地方，整个系统自动更新。
- 缺点： 以前大家觉得这种“只画图不写咒语”的方法太简单，算不了复杂的数学题，甚至被认为不够“聪明”（图灵不完备）。

核心问题： 以前，这两个王国是割裂的。你想做复杂的计算，就得用魔术师的方法；你想管理配置，就得用设计师的方法。没人能把它们完美地统一起来。

2. 新世界的核心：乐高积木与“深合并”

这篇文章的作者 Bo Yang 提出：其实，我们不需要那么复杂的魔法。只要把“继承”这个概念用到极致，就能同时解决所有问题。

他引入了三个最基础的积木：

记录（Record）： 就像一个个乐高小盒子，里面装着各种属性（比如“颜色”、“大小”）。
定义（Definition）： 在盒子上贴个标签，写上内容。
继承（Inheritance）： 把两个盒子融合在一起。

关键创新点：深合并（Deep Merge）

想象你有两个乐高盒子：

盒子 A 里有一个红色的轮子。
盒子 B 里有一个蓝色的轮子，还有一个引擎。

在传统的编程（比如 Java 或 C++）里，如果你把 B 继承给 A，通常会发生“覆盖”：B 的红色轮子会把 A 的红色轮子替换掉，或者系统会报错说“冲突了”。

但在继承演算里，发生的是**“深合并”**：

系统不会覆盖，而是把 A 和 B 里的东西全部拼在一起。
如果两个盒子都有“轮子”，系统会认为它们是两个不同的轮子，或者智能地把它们合并成一个更复杂的结构。
结果： 你得到了一个既有红色轮子、又有蓝色轮子、还有引擎的超级盒子。

这就像什么？
就像你在装修房子。

旧方法：如果你想在客厅加个书架，但墙上已经有个画了，你必须把画撕下来（覆盖），或者装修队会罢工（报错）。
新方法（继承演算）：你直接把书架挂在墙上，画还在，书架也在，甚至如果书架和画重叠，它们会自动融合成一个“带画的书架”。

3. 这个新世界有多强？

作者证明了，用这种简单的“拼盒子”方法，竟然能做出以前只有“魔术师”才能做到的事：

它比魔法更强大： 它可以模拟所有的数学计算（图灵完备）。甚至，有些在旧魔法世界里会死循环（算不出来）的程序，在这个新世界里能算出结果。
它解决了“表达式问题”： 这是编程界的一个著名难题。简单说，就是“想给旧系统加新功能，却不得不修改旧代码”。
- 比喻： 以前，如果你想给一辆汽车加个“自动驾驶”功能，你得把发动机拆了重写。
- 现在： 你只需要把“自动驾驶模块”这个新盒子，拼到汽车上。原来的发动机、车轮、座椅都完好无损，新模块自动接管了相关部分。而且，你可以同时拼上“自动驾驶”和“自动洗车”两个模块，它们互不干扰，完美共存。
它自动处理“多重继承”的混乱： 在旧世界里，如果一个类继承了两个都有“刹车”功能的父类，系统会晕掉（不知道听谁的）。在这个新世界里，系统会认为“刹车”有两个来源，它们会自动合并，就像把两个刹车片叠在一起，反而刹得更稳。

4. 生活中的奇妙现象

作者还发现了一些意想不到的“副作用”：

逻辑编程的自动涌现： 当你用这种“拼盒子”的方式做算术时，它会自动变成一种“关系数据库”的逻辑。
- 比喻： 你本来只想算 $1+2 $，但因为你的盒子是“集合”的，它会自动帮你算出$ 1+2 $、$ 1+3 $、$ 2+2 $、$ 2+3$ 等等所有可能的组合。这就像你问“谁是我的朋友”，它不仅能告诉你名字，还能告诉你所有朋友的朋友，自动形成一张关系网。
函数颜色的盲视： 在旧编程里，区分“同步”（一步一步做）和“异步”（边做边等）非常麻烦，代码要改来改去。但在这种新语言里，业务逻辑只是“空盒子”，具体的“同步”或“异步”实现只是后来拼上去的盖子。
- 比喻： 你设计了一个“咖啡机”的图纸（业务逻辑）。你可以先拼上一个“手摇”的盖子（同步），也可以拼上一个“电动”的盖子（异步）。图纸本身完全不用改，就能适应两种情况。

5. 总结：为什么这很重要？

这篇文章告诉我们，编程不一定非要写复杂的“函数”和“循环”。

通过一种极简的、基于**“记录合并”**的思维方式，我们可以构建出：

更灵活的配置系统（像 NixOS 那样管理整个操作系统）。
更强大的计算模型（能算出以前算不出的东西）。
永远可扩展的代码（想加功能就加，永远不用改旧代码）。

一句话总结：
这就好比我们一直以为盖房子必须用砖头（函数）一块块砌，或者用图纸（配置）画出来。作者发现，其实只要用一种**“智能乐高”，把不同的模块直接融合**在一起，不仅能盖出摩天大楼（复杂计算），还能让房子随时随意扩建（解决扩展性问题），而且永远不用担心模块之间会打架。

这就是**“继承演算”**：用最简单的“拼合”规则，构建最复杂的软件世界。

Each language version is independently generated for its own context, not a direct translation.

《继承演算》（A Calculus of Inheritance）技术总结

1. 研究背景与问题 (Problem)

在现代软件工程领域，声明式语言（Declarative Languages）和配置语言（如 NixOS 模块、Jsonnet、CUE、Dhall 等）被广泛用于管理复杂系统的配置。这些语言的核心机制通常基于继承（Inheritance）或合并（Merging）来组合结构化数据。

然而，现有的计算理论存在以下缺口：

缺乏基础模型：函数式编程拥有 $\lambda$ -演算作为理论基础，但声明式编程缺乏一个类似的、形式化的计算模型。
现有模型的局限性：
- 图灵机（Turing Machine）和 RAM 机需要可变状态（Mutable State）。
- $\lambda$ -演算需要一等函数（First-class Functions）。
- 配置语言通常要求值不可变且没有一等函数。
- 现有的计算模型无法在满足“图灵完备、不可变、无函数”这三个约束的同时，解释 NixOS 等系统为何具有如此高的表达能力。
多重继承的线性化问题：在面向对象编程（OOP）和 Mixin 系统中，多重继承通常面临“菱形问题”（Diamond Problem），需要复杂的线性化算法（如 C3 线性化）来解决方法解析顺序，这破坏了组合的交换律、结合律和幂等性。
表达式问题（Expression Problem）：许多系统难以在不修改现有代码的情况下，同时扩展新的数据类型和新的操作。

2. 方法论 (Methodology)

作者提出了一种名为继承演算（Inheritance-calculus）的极简计算模型，旨在作为声明式编程的基础。

2.1 核心原语

继承演算仅包含三个原语，对应 $\lambda$ -演算中的抽象、应用和变量：

记录（Record）：{c1, ..., cm}，表示一组元素的集合。
定义（Definition）：l -> e，定义属性。
继承（Inheritance）：[l_up.this. | ↑n.] l_down...，表示从作用域向上导航并向下投影属性。

2.2 核心机制

深度合并（Deep Merge）：继承被建模为集合的并集（Set Union）。由于集合运算天然具有交换律（Commutative）、幂等律（Idempotent）和结合律（Associative），因此多重继承的线性化问题被结构性地消除。
Mixin 树（Mixin Tree）：所有的类、方法、对象和属性都被统一为“可深度合并的 Mixin"。没有不透明的方法，所有值都是透明的记录。
观察语义（Observational Semantics）：计算由观察者驱动。语义通过查询树中的路径（Path）来确定。
一阶语义（First-order Semantics）：语义定义基于六个相互递归的一阶函数（properties, supers, overrides, bases, resolve, this），仅涉及路径和路径集合的集合论操作，不包含函数空间、闭包或策略。
不动点计算：语义定义为单调立即后果算子（Immediate Consequence Operator, $T_P$ ）的最小不动点（lfp），这使得递归程序即使在某些 $\lambda$ -演算中发散，在继承演算中也能收敛。

2.3 实现与验证

作者基于该理论开发了 MIXINv2（Python 实现），并验证了以下特性：

实现了布尔逻辑、自然数算术（一元和二元）和 Web 应用。
证明了该模型在 Felleisen 意义下比 $\lambda$ -演算具有更严格的表达能力。
展示了“函数颜色盲”（Function Color Blindness）现象，即同一份代码可无缝运行在同步或异步环境中。

3. 主要贡献 (Key Contributions)

提出了继承演算：一个包含记录、定义和继承三个构造的极简计算模型，作为声明式编程的基础。
统一了抽象：Mixin 作为单一抽象，统一了类、方法、对象和属性。方法重写被深度合并所取代，消除了 OOP 中的线性化问题。
一阶不动点语义：
- 定义了基于路径查询的六个一阶语义方程。
- 证明了该语义是完全抽象（Fully Abstract）的，对应于 $\lambda$ -演算的 Böhm 树等价性。
- 揭示了 $\lambda$ -演算可以宏式地嵌入到继承演算中（5 条局部规则），但反之不成立。
表达能力的不对称性：
- 证明了继承演算在 Felleisen 的意义上严格比惰性 $\lambda$ -演算更强大。
- 通过“开放扩展”（Open Extension），可以在不修改现有定义的情况下添加新的可观察投影，从而区分在 $\lambda$ -演算中等价的项。
解决表达式问题：
- 通过深度合并，新操作和新数据类型可以独立添加，无需修改现有代码。
- 展示了 Church 编码的自然数在继承演算中自动形成 Trie 结构，算术运算自动产生笛卡尔积，从而自然地实现了逻辑编程的关系语义。
函数颜色盲（Function Color Blindness）：业务逻辑声明抽象属性槽，具体的同步/异步实现通过继承注入。同一份代码无需修改即可适应不同的运行时环境。

4. 关键结果 (Results)

图灵完备性：通过将 $\lambda$ -演算（ANF 形式）嵌入继承演算，证明了继承演算是图灵完备的。
收敛性差异：某些在 $\lambda$ -演算中因 $\beta$ -归约而发散的递归程序（如 let x = x in x），在继承演算的不动点语义（lfp( $T_P$ )）下可以收敛（表现为未定义值而非发散）。
关系语义的涌现：在案例研究（Nat Arithmetic）中，普通的算术运算（如加法）在组合多个值（Trie 并集）时，自动产生了逻辑编程中的关系语义（Relational Semantics）。例如，{1, 2} + {3, 4} 自动计算为 {4, 5, 6}（所有可能的配对和）。
多路径自引用的解决：在 Scala 或 NixOS 模块系统中，多重继承路径导致的自引用（this）会引发冲突或错误。而在继承演算中，this 解析为多目标集合，所有路径平等贡献，通过集合去重自然解决冲突。

5. 意义与影响 (Significance)

理论填补：为声明式编程提供了首个形式化的计算基础，填补了“不可变、无函数、图灵完备”这一计算模型领域的空白。
重新定义继承：将继承从“方法覆盖”提升为“结构深度合并”，从根本上解决了多重继承的复杂性，使得组合操作具有数学上的完美性质（交换、结合、幂等）。
配置语言的理论基础：解释了 NixOS 等配置系统为何如此强大，并为未来设计更强大的配置语言提供了理论指导。
解决表达式问题：提供了一种结构上免疫于“不可扩展性”的机制，使得软件架构在添加新功能和数据类型时无需重构。
跨范式融合：展示了函数式编程、面向对象编程和逻辑编程（Datalog）在继承演算中的统一。逻辑编程的查询和递归可以通过简单的路径查询和不动点计算自然实现。
工程实践启示：MIXINv2 的实现证明了该理论的可执行性，为构建下一代声明式配置语言和模块化软件架构提供了新的范式。

总结：
《继承演算》不仅是一个新的计算模型，更是对软件组合机制的一次深刻重构。它通过集合论（Set Theory）和不动点语义（Fixpoint Semantics）统一了多种编程范式，证明了通过简单的“记录”和“继承”原语，即可构建出比传统 $\lambda$ -演算更强大、更灵活且天然支持声明式扩展的计算系统。

A Calculus of Inheritance