1. 为什么还要再造一门编程语言
1.1 从一次深夜重构说起
三年前的一个凌晨，我盯着屏幕上那堆超过两千行的配置文件，心里只有一个念头：这东西不该长这样。那是一个数据管道项目，业务逻辑本身并不复杂，无非是读取、清洗、聚合、落库这几步，但为了实现这些，我写了大量的胶水代码、配置片段、类型声明和异常处理。真正表达业务意图的代码可能不到两百行，剩下的全是在伺候工具链。
那个夜晚之后，我开始认真思考一个问题：我们到底需要什么样的编程语言？市面上的语言已经够多了，从底层的 C、Rust，到应用层的 Python、Go、TypeScript，再到各种领域特定语言，几乎每个细分场景都有对应的选择。但奇怪的是，当我试图用一种语言同时表达“数据结构的形状”“业务流转的规则”和“运行时的行为”时，总是要在几种范式之间来回切换，写出来的代码像缝合怪。
CatBase 就是在这个背景下诞生的。它不是要取代谁，也不是要挑战什么排行榜上的位置，它只是我想解决自己实际问题的一个尝试。这篇文章我会把整个开发过程中的思考、取舍、踩过的坑，以及一些可以直接参考的实现细节都摊开来讲。如果你也在做类似的事情，或者单纯对编程语言设计感兴趣，应该能从中找到一些有用的东西。
1.2 CatBase 到底想解决什么问题
先说清楚 CatBase 的定位。它是一门面向数据流转与规则表达的通用编程语言，核心设计目标有三个：第一，让数据结构的定义和操作尽可能自然；第二，让规则和约束成为语言的一等公民，而不是靠外部框架或注解来补；第三，保持足够的表达力，能覆盖从脚本到中型服务的场景。
用一句话概括：CatBase 试图在“配置的简洁”和“代码的灵活”之间找到一个平衡点。它不像 YAML 那样只能描述静态结构，也不像通用语言那样需要大量样板代码来表达简单的数据变换。
我给它起名 CatBase，是因为整个语言的核心抽象围绕“类别”和“基础”两个概念展开。类别代表数据的类型和结构，基础代表操作和变换的起点。这个名字听起来有点随意，但用久了会发现它和语言的设计哲学是契合的：一切从基础出发，按类别组织。
1.3 适合谁来了解 CatBase
如果你日常工作中大量处理数据转换、规则校验、流程编排，并且厌倦了在多种工具之间来回切换，CatBase 的设计思路可能对你有参考价值。如果你正在考虑自己设计一门小语言或领域特定语言，那这篇文章里的很多决策过程可以直接借鉴。
即使你完全不打算用 CatBase，只是想了解一门编程语言从想法到落地要经历哪些环节，这篇文章也会给你一个相对完整的视角。我会尽量少讲空泛的理念，多讲具体的实现和真实的取舍。
2. 语言设计的核心思路与取舍
2.1 为什么不做成纯配置语言
最开始我考虑过把 CatBase 做成纯配置语言，类似 YAML 或 HCL 的增强版。这样实现成本低，用户上手也快。但很快发现这条路走不通。纯配置语言最大的问题是缺乏抽象能力。当你需要复用一段逻辑、根据条件动态生成结构、或者定义可组合的规则时，配置语言就会变得非常笨拙。
我试过用 YAML 的锚点和引用来模拟函数，用条件字段来模拟分支，结果写出来的东西比直接写代码还难维护。所以 CatBase 从一开始就定位为通用编程语言，只是语法和运行时针对数据场景做了大量优化。它支持函数、闭包、模块、错误处理这些通用语言该有的东西，只是在表达数据结构和规则时更顺手。
这个决策带来的代价是语言实现复杂度大幅上升。纯配置语言只需要一个解析器和求值器，而通用语言需要完整的词法分析、语法分析、类型检查、代码生成或解释执行。但我觉得这个代价是值得的，因为抽象能力是刚需，不能妥协。
2.2 语法风格的选择逻辑
CatBase 的语法借鉴了几个方向。表达式部分接近 Python 和 Ruby，强调可读性和简洁；类型声明部分参考了 TypeScript 和 Rust，但做了简化；规则和约束的写法则更接近逻辑编程语言，用声明式的方式表达“什么必须成立”而不是“怎么检查”。
举个例子，定义一个用户结构并附加约束，在 CatBase 里大概是这样：
category User { id: Int name: String email: String age: Int rule age >= 0 && age <= 150 rule email matches /\S+@\S+\.\S+/ }这段代码同时表达了数据结构、字段类型和业务规则。在传统语言里，结构定义和校验逻辑通常是分开的，要么写在不同的地方，要么靠装饰器或注解来关联。CatBase 把它们放在一起，是因为它们本来就是一件事：描述一个用户应该长什么样。
语法设计上我坚持一个原则：常见操作要短，罕见操作可以长。数据结构的定义、字段访问、条件判断、循环遍历，这些每天要写几十遍的东西必须简洁。而一些高级特性，比如自定义运算符、元编程接口，可以稍微啰嗦一点，反正不常用。
2.3 类型系统的设计权衡
类型系统是语言设计里最纠结的部分。静态类型能提前发现错误，提升代码可维护性，但会增加书写负担。动态类型写起来爽，但大型项目里容易失控。CatBase 选择了一条中间路线：渐进式类型。
默认情况下，变量和函数参数可以不写类型，运行时动态推断。但你可以随时加上类型标注，编译器会做检查。更重要的是，CatBase 的类型系统对数据结构有特殊支持。你可以定义结构化类型，然后让编译器自动推导字段访问的合法性。
fn greet(user) { return "Hello, " + user.name } fn greetTyped(user: User) -> String { return "Hello, " + user.name }上面两个函数功能一样，但第二个有完整的类型标注。在小型脚本里用第一种，快速灵活；在核心业务逻辑里用第二种，安全可靠。这种渐进式的设计让 CatBase 既能当脚本语言用，也能支撑中型项目。
类型推导的实现比预想的要复杂。尤其是当结构类型、联合类型和泛型混在一起时，推导算法很容易爆炸。我最后采用了一种基于约束的推导方案，把类型关系转化成约束求解问题，虽然性能不是最优，但正确性有保障。
2.4 运行时形态的决策过程
CatBase 的运行时我考虑过三种方案：直接解释执行、编译到字节码、编译到目标语言源码。直接解释最简单，但性能差；编译到字节码性能好，但实现工作量大；编译到目标语言源码可以借助现有生态，但调试和错误信息会很难看。
最终我选择了字节码方案，但做了一个简化：不追求极致的性能优化，优先保证实现清晰和可调试。字节码指令集设计得很紧凑，大概六十多条指令，覆盖了数据操作、控制流、函数调用和规则检查。虚拟机是一个简单的栈式机，每个操作数栈帧对应一个函数调用。
这个选择的好处是启动速度快，不需要额外的编译步骤，同时性能比纯解释好不少。代价是我需要自己实现垃圾回收、异常处理、调试接口这些基础设施。好在这些都有成熟的方案可以参考，不算从零发明。
3. 核心细节解析与实操要点
3.1 数据结构定义的语法细节
CatBase 里定义数据结构用category关键字，后面跟名称和一对花括号。字段声明是名称: 类型的形式，类型可以是内置类型，也可以是其他 category。字段可以有默认值，用=指定。
category Order { id: Int items: List<OrderItem> status: String = "pending" createdAt: DateTime = now() total: Decimal } category OrderItem { productId: Int quantity: Int price: Decimal }这里有几个设计细节值得说明。第一，字段默认值可以是表达式，比如now()，这意味着默认值是在运行时求值的，不是编译期常量。第二，List<OrderItem>这种泛型写法借鉴了主流语言，但 CatBase 的泛型只支持结构类型，不支持高阶类型，这是为了控制实现复杂度。第三，Decimal是内置的精确小数类型，因为数据场景里浮点数精度问题太常见了，必须从语言层面解决。
定义好结构后，创建实例可以用字面量语法：
let order = Order { id: 1001, items: [ OrderItem { productId: 1, quantity: 2, price: 29.90 }, OrderItem { productId: 5, quantity: 1, price: 99.00 } ], total: 158.80 }这种写法比构造函数调用更直观，也比 JSON 更安全，因为编译器会检查字段名和类型。如果你写错了字段名，或者漏了必填字段，编译期就会报错，不用等到运行时才发现。
3.2 规则系统的实现原理
规则是 CatBase 最有特色的部分。在 category 内部用rule关键字声明约束，规则表达式会在实例创建和修改时自动检查。规则可以引用当前实例的字段，也可以调用函数。
category Account { balance: Decimal frozen: Bool = false rule balance >= 0 rule frozen implies balance == 0 }规则系统的实现分两步。第一步是语法分析时把规则表达式收集起来，绑定到对应的 category 上。第二步是运行时在实例创建和字段修改时触发规则检查。如果规则不满足，会抛出RuleViolation异常，包含违规的规则表达式和当前实例的快照。
这里有个性能考量：不是所有规则都需要每次检查。有些规则只在创建时检查一次，有些规则在特定字段修改时才需要检查。CatBase 允许给规则加触发条件：
rule balance >= 0 on update(balance) rule frozen implies balance == 0 on update(frozen, balance)这样运行时可以精确知道哪些规则需要重新求值，避免不必要的计算。对于大型数据结构，这个优化能显著降低开销。
规则表达式的求值是在一个受限的环境里进行的，只能访问当前实例的字段和内置的纯函数。这是为了防止规则产生副作用，保证规则检查的幂等性和可预测性。如果你需要在规则里做复杂计算，可以调用预先注册的纯函数。
3.3 函数与闭包的实现方式
CatBase 的函数是一等公民，可以赋值给变量、作为参数传递、从函数返回。闭包捕获外部变量的方式是按值捕获，不是按引用。这个决策是为了简化实现，避免循环引用和内存泄漏的复杂性。
fn makeCounter() { let count = 0 return fn() { count = count + 1 return count } } let counter = makeCounter() counter() // 1 counter() // 2注意这里的count是被闭包捕获的局部变量。按值捕获意味着闭包内部修改count不会影响外部的count，但因为外部作用域已经结束，实际上只有闭包自己能看到这个变量。这种语义和 JavaScript 的闭包类似，但更简单，因为不涉及引用共享。
函数调用采用传值语义，但结构类型在传递时是浅拷贝。这意味着如果你传一个 category 实例给函数，函数内部修改字段不会影响原实例，但如果字段本身是引用类型（比如 List），修改列表内容会影响原实例。这个设计是为了平衡性能和安全性，避免每次调用都做深拷贝。
3.4 错误处理机制的设计
CatBase 的错误处理采用异常机制，但和主流语言有些不同。所有异常都是值，可以像普通数据一样传递和检查。语言内置了Result类型，用于表示可能失败的操作。
fn divide(a: Decimal, b: Decimal) -> Result<Decimal, String> { if b == 0 { return Error("division by zero") } return Ok(a / b) } let result = divide(10, 0) match result { Ok(value) -> print("result: " + value) Error(msg) -> print("error: " + msg) }这种设计的好处是错误处理显式化，编译器可以检查你是否处理了所有可能的错误分支。同时，异常机制仍然保留，用于处理不可恢复的错误，比如规则违规、类型错误、资源耗尽。
我试过完全去掉异常，只用 Result 类型，但发现对于深层嵌套的调用链，Result 的传播太啰嗦。所以最终保留了异常作为补充，但建议在业务逻辑里优先使用 Result。
4. 实操过程与核心环节实现
4.1 从零搭建语言原型的步骤
如果你也想自己实现一门语言，我把我走过的路径整理一下。第一步是定义语法，写一个简单的文法文件，用 EBNF 或者类似的形式描述语言结构。CatBase 的文法大概有两百多行，覆盖了表达式、语句、声明和规则。
第二步是实现词法分析器。我手写了一个状态机，没有用 lex 或 flex 这类工具。手写的好处是错误信息更友好，性能也更好控制。词法分析器把源码拆成 token 流，每个 token 包含类型、值和位置信息。
第三步是实现语法分析器。我用的是递归下降法，每个语法规则对应一个函数。递归下降的代码可读性好，调试方便，缺点是对于左递归文法需要改写。CatBase 的文法设计时已经避免了左递归，所以实现起来很直接。
第四步是构建抽象语法树。语法分析器直接生成 AST 节点，每个节点包含类型、子节点和位置信息。AST 是后续所有处理的基础，所以设计时要考虑周全，既要包含足够的语义信息，又要保持结构清晰。
第五步是实现解释器或编译器。我先写了一个简单的树遍历解释器，验证语言特性，然后再改成字节码编译器。树遍历解释器虽然慢，但开发速度快，适合早期迭代。
4.2 字节码虚拟机的关键实现
字节码虚拟机的核心是一个循环，不断从指令流中读取指令并执行。CatBase 的虚拟机大概有六十多条指令，分为几类：栈操作、算术运算、比较运算、控制流、函数调用、数据操作、规则检查。
loop { let instruction = code[pc] pc = pc + 1 switch instruction.opcode { case OP_CONST: stack.push(instruction.operand) case OP_ADD: let b = stack.pop() let a = stack.pop() stack.push(a + b) case OP_JUMP: pc = instruction.operand // ... 其他指令 } }这个循环看起来简单，但细节很多。比如栈溢出检查、类型检查、异常处理、调试钩子，都需要在合适的位置插入。我用了宏来生成指令处理代码，减少重复，同时保持性能。
函数调用是虚拟机里最复杂的部分。每次调用需要创建新的栈帧，保存返回地址、局部变量和操作数栈。CatBase 的栈帧是动态分配的，因为闭包捕获的变量数量不固定。栈帧的分配和回收用了一个简单的空闲列表，避免频繁的内存分配。
4.3 规则检查的运行时集成
规则检查的集成点有三个：实例创建、字段修改、显式调用。实例创建时，所有标记为on create的规则会被检查。字段修改时，所有引用了被修改字段的规则会被检查。显式调用时，可以通过validate()方法触发所有规则检查。
category Product { price: Decimal discount: Decimal = 0 rule price > 0 rule discount >= 0 && discount < price on update(discount, price) }当discount被修改时，第二条规则会被触发。如果新值不满足规则，修改会被拒绝，抛出异常。这个机制保证了对象始终处于合法状态，不会出现中间态。
实现上，每个 category 在编译期会生成一个规则依赖表，记录每条规则依赖哪些字段。运行时修改字段时，查表找到需要检查的规则，依次求值。这个表是静态生成的，不需要运行时构建，所以开销很小。
4.4 性能优化的实际手段
语言实现完成后，我做了一轮性能优化。主要手段有三个：常量折叠、内联缓存、尾调用优化。
常量折叠在编译期进行，把2 + 3这样的表达式直接替换成5。这个优化对数据场景特别有效，因为很多配置值都是常量表达式。
内联缓存在运行时进行，缓存字段访问和方法查找的结果。CatBase 的对象模型是动态的，字段访问需要查表，开销不小。内联缓存把最近一次查找的结果缓存起来，下次访问同一字段时直接命中。
尾调用优化针对递归函数，把尾递归转换成循环，避免栈溢出。这个优化对规则检查特别重要，因为规则可能递归引用其他规则。
优化之后，CatBase 的执行速度大概提升了三到五倍，对于数据转换场景已经够用了。当然和编译型语言还有差距，但考虑到开发效率和表达力，这个性能水平是可以接受的。
5. 常见问题与排查技巧实录
5.1 规则冲突与循环依赖的处理
规则系统最常见的问题是循环依赖。比如规则 A 依赖字段 x，规则 B 依赖字段 y，而修改 x 会触发规则 B，修改 y 会触发规则 A，形成死循环。
CatBase 的解决方案是在规则依赖表里检测循环。如果发现循环，编译期就报错，而不是等到运行时死循环。检测算法用的是拓扑排序，如果无法完成排序，说明存在循环依赖。
category Node { value: Int parent: Node? rule value >= 0 rule parent == null || parent.value >= 0 }上面这个例子中，parent字段引用了另一个 Node，规则检查会递归进行。如果 parent 链形成环，规则检查会无限递归。CatBase 在运行时检测到这种情况会抛出CircularRuleDependency异常，并打印出依赖链，方便定位问题。
5.2 类型推导失败的排查思路
渐进式类型系统的类型推导有时会失败，尤其是当代码里混用了动态类型和静态类型时。常见的失败场景包括：函数返回值类型不明确、泛型参数无法推断、联合类型分支不完整。
排查类型推导问题，我通常从这几个方向入手。第一，检查函数签名，确保参数和返回值类型明确。第二，检查泛型调用，确保类型参数可以从上下文推断出来。第三，检查条件分支，确保所有分支返回兼容的类型。
CatBase 的类型检查器会输出详细的错误信息，包括推导过程中的约束和冲突点。如果错误信息不够清楚，可以用--explain-types选项让编译器打印完整的推导过程。
5.3 性能瓶颈的定位方法
CatBase 程序变慢时，定位瓶颈的方法和主流语言类似。首先用--profile选项运行，生成性能报告，看时间花在哪些函数上。然后针对热点函数做优化，比如减少对象创建、避免不必要的规则检查、使用更高效的数据结构。
我遇到过一个典型问题：一个数据转换脚本处理十万条记录时耗时超过预期。用 profiler 一看，大部分时间花在规则检查上。原因是每条记录创建时都触发了所有规则检查，而其中很多规则是重复的。解决方案是把规则分成两类：创建时检查的规则和修改时检查的规则，减少不必要的检查。
另一个常见问题是字符串拼接。CatBase 的字符串是不可变的，大量拼接会产生很多临时对象。解决方案是提供StringBuilder类型，或者用join方法一次性拼接。
5.4 常见错误速查表
| 错误信息 | 可能原因 | 解决方法 |
|---|---|---|
| RuleViolation | 规则不满足 | 检查规则表达式和字段值 |
| CircularRuleDependency | 规则循环依赖 | 重构规则，打破循环 |
| TypeMismatch | 类型不匹配 | 检查变量类型和函数签名 |
| UndefinedField | 字段未定义 | 检查 category 定义 |
| StackOverflow | 递归过深 | 改用迭代或尾递归 |
| OutOfMemory | 内存不足 | 检查是否有内存泄漏 |
这张表是我在实际开发中总结的，覆盖了大部分常见错误。遇到问题时先查表，能快速定位方向。
5.5 调试技巧与工具使用
CatBase 提供了几个调试工具。--dump-ast可以打印抽象语法树，帮助理解代码结构。--dump-bytecode可以打印字节码，帮助分析执行流程。--trace可以跟踪函数调用和规则检查，帮助定位逻辑错误。
我常用的调试流程是：先用--dump-ast确认语法解析正确，再用--trace跟踪执行流程，最后用--profile分析性能。这套流程能解决大部分问题。
还有一个技巧是在代码里插入debug()函数调用，打印变量值和执行位置。debug()在正式运行时会被忽略，不影响性能，所以可以放心留在代码里。
6. 语言后续扩展与个人体会
CatBase 目前还在持续迭代中。接下来我计划加入几个特性：模式匹配、异步支持、包管理。模式匹配对数据场景特别有用，可以简化复杂结构的解构。异步支持是为了处理 IO 密集型任务。包管理是为了让代码复用更方便。
实现这些特性的过程中，我最大的体会是：语言设计没有银弹，每个决策都有代价。静态类型安全但啰嗦，动态类型灵活但容易出错。规则系统强大但可能影响性能。关键是找到适合目标场景的平衡点，而不是追求理论上的完美。
另一个体会是：工具链和生态比语言本身更重要。一门语言再好，如果没有好用的编辑器支持、调试工具、包管理，也很难推广。CatBase 目前只在我自己的项目里使用，很大原因就是生态还不完善。
最后分享一个小技巧：如果你也在设计语言，建议从最小可用原型开始，先跑通一个简单的例子，再逐步扩展。不要一开始就追求完整，那样很容易陷入细节，迟迟看不到成果。我最初版本的 CatBase 只支持整数和字符串，连函数都没有，但已经能验证核心想法了。后续的迭代都是在这个基础上逐步添加的。
