Chim 2.0语法规范详解：从词法到类型系统的严格化改造

正经做过解释器的人都知道一门语言能不能活得长久三分靠运行时能力七分靠语法规范。Chim启语2.0 就是一门把语法规范当作核心资产来打磨的小型脚本语言定位在结构化配置、数据清洗和快速原型脚本之间。2.0 版本最大的变化不是加了多酷的语法糖而是重新定义了整套词法、语法和类型约束边界把 1.x 时代那些“写起来爽、跑起来懵”的模糊地带全部钉死。这份规范面向的读者不只是语言设计者。如果你正在写自己的解析器、做 DSL 的语法骨架或者只是每天用 Chim 写数据任务都应该通读一遍。它能让你少踩很多“为什么这里要加分号”“为什么这个函数可以访问外部变量”的坑。接下来的内容我会按词法、核心语法、类型系统、模块和错误处理几个维度拆开讲并结合我在迁移旧脚本时踩过的真实问题来做说明。1. 语法规范的整体定位与设计取舍1.1 为什么2.0要重写语法骨架Chim 1.x 的语法其实不算难用最大问题是“宽容”。当年为了让大家快速上手1.x 允许省略很多标点还引入了自动分号插入机制。好处是脚本看起来干净坏处是同一个表达式在换行位置不同时解析结果会不一样。我在 1.x 时代就吃过亏一个有问题的换行让数组在赋值时被解释成了调用定位问题花了两天。2.0 的设计初衷就是消除这种歧义。规范里明确了三个原则第一语句边界必须显式可见分号不能省第二块结构使用大括号不允许“无括号单语句”这种缩进魔法第三保留字列表全部小写连True这种首字母大写的别名都删掉了。这样做的代价是代码看起来稍微啰嗦了一点但解析器实现起来干净很多IDE 补全和语法高亮也更容易做。对于已有 1.x 代码库的团队迁移确实有一定成本但规范里提供了“兼容标记”// 2.0 严格语法 strict on // 1.x 宽松语法仅用于过渡 lang 1.x在文件头部用lang 1.x可以临时启用旧规则但这种模式不保证长期可用。官方计划在 2.4 版本后彻底移除此分支所以建议新文件一律从 strict 模式起步。1.2 兼容旧版脚本的迁移策略如果你手头有大量 1.x 脚本不要指望一把梭哈全部重写。我实践的迁移顺序是先跑一遍官方提供的chim migrate工具它会自动插入缺失的分号、把-箭头函数改成fn关键字、把let定时任务改为every块。剩下的手工修改点主要集中在隐式返回和字符串插值这两块。1.x 里函数最后一行表达式会被默认当作返回值2.0 里必须显式写return。这个改动影响最大因为很多短函数原本是“小清新”风格fn add(a, b) { a b // 1.x 会自动返回2.0 会报错 }迁移后必须改成fn add(a, b) { return a b }字符串插值方面1.x 允许在双引号字符串里裸写变量名例如hello $name2.0 统一要求写成hello ${name}。这主要是为了避免在拼接 URL 时误把$符号当成变量前缀。如果你做过 Web 方向的数据脚本应该能理解这种严格化带来的安全感。2. 词法规则格式化细节决定解析成败2.1 标识符、保留字与命名约定词法是所有语法规范的地基。2.0 的标识符只允许以下三种形态小写开头的驼峰命名userName、fetchData下划线开头表示私有_tempValue、__internalCache中文等 Unicode 字符开头允许但全保留字列表内不可使用保留字一共 36 个我列几个容易踩坑的保留字用途容易混淆的点fn函数声明不能再作为变量名1.x 允许函数名用functionvar可变变量声明时必须初始化否则编译时报错const常量绑定与 1.x 的let语义不同let已废弃match模式匹配和 1.x 里的switch共存但match没有隐式贯穿rescue错误处理只能用于try块内部不能单独出现every定时任务2.0 新增用于周期执行块命名约定上规范里特别强调了“下划线私有”的边界_开头的成员只能在声明它的模块内被访问跨模块一律禁止。这是很多脚本语言都没有的强约束实际使用中很管用可以避免在模块导出时不小心把内部状态暴露出去。标识符长度没有上限但规范建议单行不超过 80 字符。这不仅是为了美观更是因为 2.0 的解析器在遇到超长标识符时会给警告担心开发者把一整条 JSON 路径塞进变量名里代码可读性会迅速下降。2.2 字面量数字、字符串与原始文本Chim 2.0 对字面量做了非常清晰的分层定义。数字类型分为三类整数int、浮点数float、高精度数字decimal。语法上最直观的变化是浮点数必须带小数点且小数部分至少一位1.0合法1.直接解析错误。这样设计主要是为了区分除法结果的两种语义。字符串方面有三种写法普通双引号字符串、单引号字符串、反引号原始字符串。区别在于转义处理双引号字符串支持转义如\n、\u4e2d。单引号字符串只支持\\和\两种转义其余反斜杠原样保留适合写 Windows 路径。反引号字符串内部不做任何转义通常用于写多行模板或正则表达式。我在解析器里调试正则时就经常用反引号字符串比如const pattern \d{4}-\d{2}-\d{2}如果这行用双引号写\d会被直接吃掉一个反斜杠正则就废了。布尔字面量只有true和false全部小写。空值只有none1.x 里的null和nil都被删掉。这个统一对多语言互操作很重要至少你不用再纠结“为什么这个接口传 null 报错”。2.3 注释、空白与行尾规则注释支持三种//行注释、/* */块注释、///文档注释。块注释不允许嵌套这个要特别说明因为我在 1.x 代码里见过注释里再套注释迁移工具会直接扔异常。文档注释///只允许放在顶层声明之前会被编译器收集成元数据后续可以生成 API 文档。空白符除了分隔 token 之外没有其他作用缩进完全不敏感。这让很多从 Python 转过来的朋友不太习惯但好处是复制粘贴代码块时不会因为 tab 和空格混用而崩溃。行尾规则在 2.0 里非常简单一条语句由一个分号结束换行本身不产生语义。不过这里有一个隐藏要求分号不能出现在大括号的下一行。比如下面的写法会报“非法空语句”if (condition) { doSomething(); ; // 这里会报错 }多数情况下没人这么写但如果你用自动化工具生成代码特别容易在块结尾不小心多打一个分号解析器会认为这是多余的空语句并给出警告。规范建议块体内不要出现空语句除非你显式写了pass。3. 核心语法结构从声明到控制流3.1 变量、常量与解构赋值2.0 声明变量有两种方式var和const。var声明后可以重新赋值但类型不能变const绑定后整个变量不可重新赋值但如果是容器类型内部元素仍可以修改。这和别的静态语言不一样需要特别注意const arr [1, 2, 3] arr[0] 9 // 合法常量只锁定绑定不锁定内容 arr [4, 5] // 非法不能再赋值解构赋值的语法比较克制只支持数组和对象两种形态不支持嵌套剩余项的默认解构。你可以这么写var [a, b] [10, 20] var {name, age} user不能在解构时直接给字段改名比如不能写var {name: userName} user。如果需要改名先解构再赋值。这个限制一开始觉得繁琐但确实让解析器逻辑简单了很多也避免了和类型标注语法混淆。变量声明强制要求初始化。var x;这种先声明后赋值的写法被彻底移除。如果你要表达“这个变量暂时为空”请显式写成var x none。这样在静态分析时就能确定每个变量的初始类型不会出现“这个变量有时是字符串有时是数字”的幽灵状态。3.2 分支与循环if/while/for 的标准姿势if语句的语法保持了熟悉的模样但条件表达式必须用圆括号括起来即使只有一个判断词也不能省略if (isReady) { run() } else if (hasError) { log() } else { stop() }规范明确禁止在else后面直接写条件也就是说else if必须分开成两个关键字如果你写了elseif会被当成非法标识符。这个细节很容易让从其他语言转过来的开发者迷惑好在报错信息里明确指出“你是不是想写 else if”。循环方面提供了while和for。for的语义和 JavaScript 保持一致支持传统的三段式写法但更推荐用迭代式遍历for (item in list) { process(item) } for (var i 0; i 10; i i 1) { // 传统写法也可用 }for...in迭代使用迭代协议容器对象必须实现iterator()方法。如果是对象字面量默认迭代的是键而不是值这个选择参考了 Lua 的逻辑因为很多数据脚本场景需要同时拿到键和值只需要在循环体内取item.key和item.value即可。跳转语句包括break、continue和return它们只能出现在对应结构体中。规范里补充了一点break不能用于match分支因为match分支天然不贯穿不需要break。如果有人试图在match里加break解析器会直接报“无法在此上下文使用 break”。3.3 函数、闭包与作用域规则函数声明统一用fn不支持匿名函数简写但可以用fn表达式赋值给变量fn add(a, b) { return a b } var multiply fn(x, y) { return x * y }函数参数可以带默认值默认值必须是常量表达式不能调用其他函数。2.0 的一个重要改进是默认参数是每次调用时重新求值的而不是在函数定义时求值一次这避免了很多动态默认值的坑尤其是默认值为可变容器时。作用域规则非常强调“块级可见”。每个大括号内部都是一个新作用域内部可以访问外层变量但不能反过来。函数内部可以修改外层变量吗答案是不能除非该变量声明时带有shared标记var shared counter 0 fn increase() { counter counter 1 // 不合法counter 是普通局部变量 } shared var counter 0 fn increase() { counter counter 1 // 合法shared 标记允许读写 }闭包捕获的规则是“在创建时捕获变量绑定而不是捕获值”所以闭包内部看到的是最新值。这个设计对事件驱动的脚本很友好但在循环里创建闭包时要注意闭包捕获的是循环变量的最终值不是每次迭代的快照。如果需要快照必须用默认参数技巧for (var i 0; i 3; i i 1) { tasks.add(fn(seq i) { return seq }) }4. 类型系统与表达式优先级4.1 渐进类型与运行时推断Chim 2.0 不是严格静态类型语言但提供了一套“渐进类型”系统。你不写类型标注时解释器会在运行时自动推断写了类型标注编译器会尽量在静态阶段做校验。类型标注的语法是冒号放在变量名后var age: int 30 const title: string hello fn parse(input: string) - int { return int(input) }比较特别的是联合类型用竖线表示var result: int | string ok联合类型只支持有限组合不允许泛型联合也不能用括号改变优先级。类型推断的最大边界是拒绝隐式数值转换。int和float混合运算时结果是float这是唯一的自动宽化规则想把float赋值给int变量必须显式调用int()否则运行时抛类型错误。类型标注不影响性能运行时依旧动态分发。那为什么要写核心是为了可读性和静态检查工具能够发现低级错误。我在实际使用中会给所有公开函数标注参数类型和返回类型内部私有函数则不标这样既节省时间又能保证模块接口清晰。4.2 集合类型与泛型约束标准库集合包括数组[]、对象{}、集合set()和哈希表hash()。语法层面数组和对象是字面量集合和哈希表必须通过构造器创建。泛型可以写在变量标注里var names: setstring set() var scores: hashstring, int hash()泛型在这个语言里不会做编译期检查它只作为“文档式约束”帮助开发者理解数据结构。如果你想严格限制容器内容必须使用官方提供的collection.typed模块var ints collection.typed(array, int) ints.add(hello) // 运行时异常这种“轻泛型、重运行时约束”的设计让类型系统不至于复杂到劝退初学者同时也保持了数据脚本所需要的确定性。4.3 运算符优先级速查表表达式优先级是语法规范里最容易被忽略、却最容易出 bug 的部分。2.0 的优先级表总共分为 10 层我梳理了一份常用速查表优先级运算符结合性1()[].?左结合2!-~await右结合3^右结合4*/%左结合5-左结合6左结合7左结合8|xor左结合9!isin左结合10andor??左结合这里最容易踩坑的是幂运算符^的结合性。数学上通常认为幂是右结合的即2^3^2等于2^(3^2)但很多脚本语言实现的是左结合。2.0 规定^为右结合所以2^3^2的结果是 512。如果你拿到一个在别的语言上写的表达式直接搬过来很可能得到不同结果。另一个需要留神的是??空值合并操作符它属于第 10 层优先级比逻辑与和逻辑或都低。这意味着a or b ?? c会被解析成a or (b ?? c)。如果希望先做or必须加括号。我在实际代码里见到过因为这里优先级理解错误而导致的空指针异常排查起来相当隐蔽。5. 错误处理与模块组织5.1 错误传播throw/try/rescue 的限定语义错误处理语法在 2.0 里做了大改。1.x 时代的catch被换成rescue并且只能捕获显式抛出throw的错误不能捕获系统级异常。这样限制的好处是你不会意外吞掉内存溢出或栈溢出这类致命问题。基本写法try { riskyOperation() } rescue (error) { log(error.message) } else { log(没有任何错误) }rescue后面必须跟随一个变量名来接收错误对象即使你不使用它也不能直接写rescue {。错误对象有三个标准字段message、code、cause。cause可以链式传递原始错误这在做多层调用时非常有用。规范里额外定义了throw的类型要求只能抛异常对象不能抛字符串或数字。如果你想抛一个简单错误可以用error(自定义消息)构造器创建异常对象。这个设计避免了各种语言里常见的“抛字符串”邪教用法至少错误处理的第一现场不会变成一个无法解析的字符串。如果你连try都不想写可以给函数声明标记throws它会让函数隐式向上层传播所有未捕获错误fn readFile(path: string) - string throws { return io.read(path) }这是我最喜欢的一个新增点它把“错误向上冒泡”从隐式行为变成了显式意图阅读代码时能一眼看出哪里可能抛错。5.2 模块、导入与命名空间隔离Chim 2.0 的模块系统基于文件路径但导入时不允许写相对路径的../跳出项目根目录这是为了防止模块互相越权访问非公开文件。模块声明有两种方式默认导出和具名导出// 文件 data.chim export const version 2.0 export fn load() { ... } export default fn init() { ... }导入时默认导出不需要大括号具名导出需要大括号import init from data import {version, load} from data模块解析规则有两个重点第一导入路径不能带扩展名解析器会按照.chim.chm.json的顺序寻找第二循环导入在编译阶段允许但运行时如果存在循环初始化的依赖会抛出“不可达模块初始化”错误。命名空间隔离在 2.0 是强制的。每个模块内部的顶层var默认私有只有export的变量才对其他模块可见。我不止一次见到初学朋友写了export之后又在模块外直接访问内部变量编译会报“符号不可见”。这是一个符合预期的错误但也说明文档里多次强调“模块边界就是安全边界”是有道理的。6. 语法到实现在落地时的几个坑6.1 解析器实现中的常见歧义如果你正在参考 2.0 规范自己实现一个解析器有几个歧义点需要提前处理。第一个歧义是泛型标注和比较运算符的冲突。hashstring, int里的尖括号会被词法分析器当成小于和大于。所以我建议自定义词法状态机在读取到时预读后续字符如果能匹配到identifier, identifier模式就切换为类型参数栈。或者更简单一点把类型参数改成方括号hash[string, int]。但规范本身定的是尖括号解析器必须做上下文判断。第二个歧义是闭包和对象调用。fn关键字后面可以直接跟参数列表或表达式但var f fn(x) { ... }和var f fn(x)容易混淆。实际上后者不是函数而是立即执行的匿名函数返回结果。为了规避歧义规范强制要求匿名函数的主体必须是大括号不允许像 JS 那样直接返回单个表达式。所以var f fn(x) x * 2非法必须写成var f fn(x) { return x * 2 }。第三个歧义涉及字符串插值的嵌套。abc ${foo(x)}里foo(x)的结尾)很容易被词法器误判为外部字符串的结束。解决方式是在进入插值表达式时临时切换字符串上下文记录嵌套深度并在匹配到}时恢复。这个机制需要在 lexer 里维护一个上下文栈。6.2 给新手的语法自检清单调语法问题时与其对着报错信息瞎猜不如用一套自检顺序排查。我在实际工作中总结了一个“四步检查法”检查语句分号。2.0 不允许省略分号先看是不是缺了分号。检查关键字大小写。保留字全部小写If、Return之类都会报错。检查模块导入路径。相对路径不要写扩展名也别用../跳出根目录。检查变量是否初始化。var x;在 2.0 里是非法语句必须显式给一个初始值。另外如果真的不确定某个语法是否合法我建议直接把这段代码写在一个孤立文件里然后用chim check test.chim做静态检查比反复猜测快得多。还有一个经验遇到解析错误时报错信息通常指向“第一个无法解释的字符”但它往往不是真正的原因。真正的原因多半在前面几个 token 处。所以排查时从报错位置往前多看几个 token不要紧盯着报错那一行。这个习惯救了我很多次尤其是写长表达式时。6.3 关于实际使用的体会这段时间把项目里的 Chim 脚本从 1.x 全部迁到 2.0 之后最大的感受是语法规范变严格了但调试时间确实少了。以前那种“换行位置不对就出现诡异 bug”的问题彻底消失IDE 的语法检查和自动补全也变得更可靠。虽然多写几个分号和return看起来没那么“优雅”但对于一个小型团队维护的数据任务来说可预测性远比极简语法重要。最后再分享一个小技巧在 2.0 规范文档里有一个“语法徽章”工具可以一键生成一段符合规范的版本声明头。我每次新建模块都会贴上version 2.0.3标记配合chim check做 CI 静态校验能保证后续 Pull Request 里不会混入语法不兼容的代码。这个习惯延续到其他语言项目后同样有效。