Rust but Lisp：探索用于 Rust 语义的 S-Expression 语法

系统编程与函数式语法的交汇点往往会催生出有趣的语言设计实验。其中一个名为 "rust-but-lisp" 的项目尝试在 Rust 的严谨安全性与高性能之间，以及 Lisp 的极简、递归的 s-expressions 结构之间架起桥梁。通过将 Rust 的语义映射到类 Lisp 语法上，该项目探索了 Rust 的力量是否可以通过不同的语法视角来表达。

The Core Concept: Rust Semantics, Lisp Syntax

核心概念：Rust 语义，Lisp 语法

从本质上讲，"rust-but-lisp" 并不是一种拥有自己运行时或垃圾回收器的全新语言。相反，它是一次语法转换的练习。该项目旨在提供一种使用 s-expressions 编写 Rust 代码的方法，实际上是将 Rust 作为目标语言，同时利用 Lisp 的结构化简单性作为源码。

正如社区成员所指出的，该项目专注于保持 Rust 精确的语义。这意味着使 Rust 具有价值的内存安全保证、所有权模型和零成本抽象都保持完好。目标是在类 Lisp 环境中呈现这些特定的语义，允许开发者在利用 Rust 高效性的同时，采用不同的代码组织结构化方法。

Community Critique and Technical Challenges

社区批评与技术挑战

尽管这种方法具有新颖性，但该项目在其实用性和技术完整性方面引发了显著的争论。

Syntactic Gaps and Complexity

语法差距与复杂性

主要的批评之一是显然缺乏对 Rust 一些最复杂语法特征的覆盖。例如，批评者指出该项目缺乏如何处理以下内容的清晰示例：

Lifetimes: 引用保持有效的时长显式注解。
The Turbofish (::<>): 用于向泛型函数提供显式类型参数的语法。

如果没有这些元素，声称该项目覆盖了 "all the syntax" 的说法会受到质疑，因为这些特征对于编写高级 Rust 代码至关重要。

The "Lisp" Identity Crisis

"Lisp" 身份危机

关于该项目是一个 "proper" Lisp 方言还是仅仅是一个语法包装器，存在一个根本性的问题。一些观察者认为，仅仅用 s-expressions 重写 Rust 并不意味着创建了一个传统意义上的 Lisp——这通常意味着具备同构性（homoiconicity）和强大的宏系统，能够将代码作为数据进行操作。

"It seems like this is more like writing Rust in an s-expression syntax instead of having a proper lisp dialect that compiles to Rust... It's quite weird-looking for someone who's done any amount of lisp programming."

"这看起来更像是用 s-expression 语法编写 Rust，而不是拥有一个可以编译到 Rust 的真正的 Lisp 方言……对于做过任何 Lisp 编程的人来说，这看起来相当奇怪。"

LLM Integration and Grammar

LLM 集成与语法

关于该项目与大语言模型（LLMs）的兼容性，出现了一个有趣的争论点。一些开发者建议，s-expressions 实际上是 AI 辅助编程的糟糕选择，因为 LLMs 经常在处理 Lisp 固有的深层嵌套和括号匹配时感到困难。

有观点认为，更符合 Algol 风格或 Pythonic 语言（LL(1) 语法）的语法更有效，因为它们与这些语言的大量训练数据更契合。这表明了人类对 Lisp 优雅性的偏好与现代 AI 编程代理的操作效率之间的张力。

Conclusion: The Value of Syntactic Experimentation

结论：语法实验的价值

虽然 "rust-but-lisp" 可能被一些人视为一种奇观而非工具，但它突显了语法与语义之间关系的更广泛讨论。通过剥离 Rust 标准的 C 风格语法并将其替换为 s-expressions，该项目迫使开发者思考语言的底层结构。

无论它是作为开发者的可行替代方案，还是仅仅作为一个小众实验，它都强调了 Rust 语义的持久吸引力以及对 Lisp 结构化纯粹性的持久着迷。