在现代编译器设计领域，Hsu的Co-Dfns APL数组编译器与BQN的实现因其独特的数组编程风格和创新的编译策略备受关注。两者均致力于通过数组操作实现高效的编译流程，但在目标、方法以及性能表现等方面呈现出明显差异。本文将深度剖析这两种编译器的核心设计理念、技术实施以及优劣比较，帮助读者全面理解数组编译器在当代程序设计中的地位与挑战。 首先，Co-Dfns项目由Aaron Hsu主导，是一种基于APL数组语言的编译器，初衷是证明利用数组编程范式能够实现编译核心部分的变换与优化。Co-Dfns着重采用数据并行风格，利用数组语言的高维整合与并行计算优势，试图将编译过程中的抽象语法树（AST）转换为低级表达，解决词法作用域绑定等复杂问题。相较于传统编译器设计，其独特之处在于几乎纯粹依赖数组操作，如扫描、分组和简单的迭代机制完成复杂的语法树变换。
这一方法理论上减少了编译步骤的时序依赖，有助于实现多核及GPU并行加速，理想状态下能够获得较短的临界路径和稳定的复杂度表现。 然而，随着项目发展，Co-Dfns逐步放宽了其严格的数组并行限制，转而使用多种混合结构，包括处理多个小数组的“each-ish”模式，虽保留较好的多核并行性，但在代码的GPU适配性方面有所减弱。并且，Co-Dfns并未实现自身的自举编译，其GPU性能相关的测试数据大多依托手工翻译的ArrayFire代码。整体上，Co-Dfns的体系结构表现出强烈的学术探索性质，专注于验证类似APL的数组语言能否承载编译器的核心逻辑。 相比之下，BQN编译器则秉持更务实的设计目标，旨在打造一个完整且功能丰富的自举编译器，同时保障良好的性能表现。BQN的设计灵感事实上直接源自Co-Dfns，但其代码实现重视在数据并行与实际开发效率间的平衡。
与Co-Dfns严格分离词法和语法分析的做法不同，BQN将除词法分析以外的所有编译步骤融合，用极其紧凑的数据平行操作实现AST的处理和中间表示（IR）生成。BQN的核心策略是利用简单的线性令牌列表，并通过重排序实现类似树遍历的逻辑，极大简化了编译步骤中迭代和递归的复杂度。 这一差异导致BQN在实现时对迭代使用极为谨慎，避免了多层嵌套的迭代语句，趋向一次性并行执行大部分处理任务。其对复杂操作的限制大幅提升了代码的可维护性和调试效率，且展现出逃离“写不见光”的数组代码刻板印象的一面。此外，BQN不仅设计了面向字节码虚拟机的后端，还为自举编译和运行时系统提供了高度抽象且相对简洁的设计，使其运行时结构更为灵活，虽然这也伴随着更高的抽象开销，但通过关键功能的本地化实现，BQN依然保持了较好的运行效率。 在编译后端与优化方面，Co-Dfns追求高效的GPU代码生成，输出依赖C++的ArrayFire库，虽然早期功能有限，但后续版本逐步支持更高维次数组和更复杂的结构。
近期版本也引入了死代码消除和基于寄存器模型的数组重用策略，尽管所用的寄存器分配算法在理论上存在较高的复杂度，但旨在最大程度复用内存与计算资源。另一方面，BQN使用自己的IR中间代码，依赖于虚拟机的基础数组操作，虽不生成针对GPU的代码，但专注于支持通用数组结构、函数合成（函数列车）及词法闭包，保持了高度的语言灵活性。BQN的优化主要通过IR解释器实现，例如基于变量生命周期的资源释放，但整体未涉足复杂的静态分析或大规模代码优化。 错误处理机制上，双方均展现出成熟的设计。BQN在错误报告时保持完整的源代码定位和详细信息，报错时包含位置跟踪机制，提升了开发体验。虽然这增加了编译器代码和运行时间的少量开销，但仅在检测到错误时启用，相比提升的用户反馈体验，代价微不足道。
Co-Dfns则在后期发展中趋向与BQN类似的错误管理体系，改善了调试流程。 在注释与文档方面，两者呈现迥异风格。Co-Dfns早期采取了极度代码注释分离甚至推行简洁代码风格，而BQN创作者认为适度的注释分布有助于代码的自解释性和维护效率，二者均体现了不同的开发哲学。Co-Dfns还尝试过部分文学化编程，透过大量注释细致描述代码功能，反映了其探索型研发的特点。 从性能角度综合观察，Co-Dfns在Aaron Hsu的论文中曾证明，在某些大规模AST节点场景下，GPU执行加速可达六倍，且对比传统多层pass nanopass实现显示显著优势。然而实际使用中，Co-Dfns的GPU性能未被广泛验证，且其仅限于核心转换阶段。
BQN的自举编译器展现出良好的CPU性能，能够稳定处理数兆字节级别代码，运行效率相较传统Java实现的BQN编译器相差无几。整体来看，两者在常规CPU环境下的表现颇为接近，显示出数组编程实践虽非性能绝对优解，但完全具备竞争力。 关于是否应采用数组风格实现编译器，观点存在较大分歧。BQN开发者倾向认为除非有特殊目标，否则使用数组方法可能增加开发难度且不一定带来性能优势，尤其是在传统编译器工具链日益成熟的背景下。相反，Co-Dfns的研究价值更多体现在提供了一种理论上基于并行数据结构的编译实现新思路，激发了编译器设计从传统标量计算向数组并行转型的可能性。 值得一提的是，Co-Dfns和BQN都面临管理复杂状态和变量顺序的挑战，这在大型项目中尤为突出。
由于数组操作的顺序敏感性，错误地使用不同的序列化策略常引发难以排查的错误。BQN投入了相当精力来统一处理不同阶段的数组顺序，努力降低这类错误的发生频次。相对而言，基于树结构的传统编译器通过显式节点表达及递归调用或许能更直观地管理状态，但在完全数据并行模型下则可能遭遇性能瓶颈。 在类型系统方面，Co-Dfns提出了“轴系统”的概念，认为静态类型检查不应着眼于传统的标量类型，而是更关注数组维度和轴的匹配。该理念试图通过自动检测数组操作中轴的兼容性，提升程序的可靠性和安全性，避免运行时的形状错误。这与C风格的静态类型系统截然不同，更适合高度动态、维度灵活的数组语言环境。
尽管该思路尚未被广泛实现，但为未来数组语言的类型系统设计提供了有价值的参考。 另外，不容忽视的是目前主流编译器所面临的优化需求，如复杂的类型检查、模板展开、多态支持、可达性分析以及自动向量化等高级功能，均难以通过纯粹的数组操作实现。这也限制了数组风格编译器在部分应用场景的推广。反观BQN编译器，由于其固定的语法和面向字节码的后端，避免了这些复杂特性，因此编译速度表现出色，也更容易实现全自举。 最后，关于GPU编译的未来展望，Co-Dfns曾尝试推动编译过程在GPU上的执行，获得了一定的理论性能提升，然而针对实际用户需求和编译任务规模，GPU带来的优势仍然有限。BQN同样保留了基于数组风格实现在GPU上运行的可能性，但鉴于本身已拥有较快的CPU性能以及其目标语言的特性，GPU加速的必要性尚未凸显。
另一方面，其他项目如基于Futhark的Pareas也在努力探索GPU编译器的可行性，尽管仍处于起步阶段，其对未来编译器架构设计给予了启示。 综上，Hsu的Co-Dfns APL数组编译器与BQN实现代表了当前数组编译器研究的两种极具代表性的思路和实践。Co-Dfns更多聚焦于探索数组并行范式在编译器设计中能达到的理论高度，强调数据结构的纯粹性和GPU适配潜力。BQN则立足于务实目标，追求平衡编译器完整功能与简洁高效的实现，展现了数组编程在实际编译任务中的应用价值。两者的比较不仅有助于理解数组语言编译的潜力与瓶颈，也为未来编译器设计方法提供了宝贵的经验与思考方向。随着硬件并行能力的不断提升和编译需求的多样化，如何巧妙融合数组编程优势与传统编译优化技术，将是编译器领域一个值得持续关注的课题。
。
