[Paper] 从独立编译到健全的语言组合

抱歉，我需要您提供要翻译的具体文本内容。请把需要翻译的段落或全文粘贴在这里，我会按照要求保留源链接并进行翻译。

概述

论文 From Separate Compilation to Sound Language Composition 解决了语言工程师长期面临的一个痛点：如何在保持语言扩展模块化的 同时 安全地单独编译它们。通过引入 nlgcheck，一个针对 Neverlang 语言工作台的静态分析插件，作者展示了可以在编译时捕获属性文法错误，而不失去现代语言工作台所承诺的灵活性。

关键贡献

• nlgcheck 工具 – 一种基于数据流的静态分析器，用于验证跨独立编译语言模块的属性访问。
• 形式化的可靠性证明 – 保证 nlgcheck 标记的任何属性相关运行时错误在实际执行时必然出现，从而消除误报。
• 与 Neverlang 的集成 – 证明该分析可以在不重新设计核心架构的情况下加入现有工作台。
• 实证验证 – 对真实 Neverlang 项目进行突变测试，显示对注入的属性文法错误检测率超过 95%，且编译时间开销可忽略不计。
• 保持独立编译 – 开发者仍可将语言扩展作为独立构件（例如 Maven/Gradle 依赖）发布，同时获得强大的静态保证。

方法论

1. Problem modeling – 作者将language extension problem形式化为属性文法的组合，其中每个扩展可能引入新的综合/继承属性。
2. Data‑flow analysis design – 他们构建了一种前向流分析，跟踪属性在模块边界之间的定义‑使用链，将每个 Neverlang 组件视为独立的控制流图。
3. Implementation in Neverlang – nlgcheck 接入 Neverlang 的编译流水线，拦截生成的 AST 和属性映射，然后在代码生成之前运行分析。
4. Mutation testing – 为评估有效性，他们自动向多个开源 Neverlang 项目注入典型的属性文法错误（例如缺失定义、类型不匹配），并测量检测率。
5. Performance measurement – 将不同规模项目的编译时间在有无 nlgcheck 的情况下进行比较，以评估实际影响。

结果与发现

数据表明，nlgcheck 在代码生成 之前 捕获了几乎所有属性相关错误，同时仅带来极小的编译时间开销——远在典型 CI 流水线可接受的容忍范围内。

实际影响

• 更安全的语言扩展 – 团队可以将语言插件（例如 DSL、定制语法）作为独立的 Maven/Gradle 构件发布，而不必担心只有在运行时才会显现的隐藏属性错误。
• 改进的 CI/CD – nlgcheck 可以作为轻量级步骤在持续集成中运行，将原本不可靠的运行时测试转化为确定性的编译时检查。
• 更易的生态系统集成 – 由于分析支持独立编译，现有的依赖管理工具（npm、pip、Cargo）可以像对待普通库一样对待语言扩展，从而简化版本管理和可复现性。
• 降低维护成本 – 及早发现属性不匹配可以减少因多个团队独立扩展基础语言而产生的“难以复现”错误。
• 对其他工作台的潜在应用 – 数据流方法与语言无关；类似的静态检查可以加入其他模块化语言工作台（如 Spoofax、Rascal），提供相同的保证。

限制与未来工作

• 范围仅限于属性文法 – nlgcheck 目前专注于属性的定义/使用；其他语义检查（例如，类型系统扩展、名称解析策略）仍不在范围内。
• 假设 Neverlang 模块是良构的 – 分析假定每个模块的内部文法已经是正确的；如果模块格式错误仍可能导致分析器中止。
• 对大规模生态系统的可扩展性 – 虽然在评估的项目中开销适中，作者指出非常庞大且高度相互依赖的语言生态系统可能需要增量分析或缓存策略。
• 未来方向 包括将框架扩展以处理 类型层扩展，集成 增量编译 以进一步缩短分析时间，并探索 跨工作台互操作性，使相同的静态保证能够在不同的语言工程平台上提供。

作者

• Federico Bruzzone
• Walter Cazzola
• Luca Favalli

论文信息

• arXiv ID: 2602.03777v1
• Categories: cs.PL, cs.SE
• Published: 2026年2月3日
• PDF: 下载 PDF