Rust but Lisp: Exploring S-Expression Syntax for Rust Semantics

系統程式設計與函數式語法的交集，經常引發語言設計上的有趣實驗。其中一個名為 "rust-but-lisp" 的專案，試圖在 Rust 的嚴格安全性與效能，以及 Lisp s-expressions 的極簡、遞迴結構之間架起橋樑。透過將 Rust 的語義映射到類 Lisp 語法上，該專案探索了 Rust 的強大功能是否能透過不同的語法視角來表達。

The Core Concept: Rust Semantics, Lisp Syntax

"rust-but-lisp" 的核心並非一種擁有自身運行時（runtime）或垃圾回收機制（garbage collector）的新語言。相反地，它是一場語法轉換的練習。該專案旨在提供一種使用 s-expressions 編寫 Rust 程式碼的方法，有效地將 Rust 視為目標語言，同時利用 Lisp 的結構簡單性作為來源語言。

正如社群成員所指出的，該專案專注於維持 Rust 精確的語義。這意味著使 Rust 具有價值的記憶體安全性保證、所有權模型（ownership model）以及零成本抽象（zero-cost abstractions）都將保持不變。目標是在類 Lisp 的環境中呈現這些特定的語義，讓開發者在利用 Rust 的效率時，也能使用不同的程式碼組織結構方法。

Community Critique and Technical Challenges

儘管這種方法具有新穎性，但該專案在其實用性與技術完整性方面引發了顯著的爭議。

Syntactic Gaps and Complexity

其中一個主要的批評點在於，該專案似乎缺乏對 Rust 最複雜語法特性的覆蓋。例如，批評者指出該專案缺乏處理以下內容的清晰範例：

• Lifetimes: 引用（references）保持有效期間長短的顯式註解。
• The Turbofish (::<>): 用於向泛型函數提供顯式類型參數的語法。

由於這些特性是編寫進階 Rust 程式碼的核心，因此對於該專案覆蓋「所有語法」的說法持懷疑態度。

The "Lisp" Identity Crisis

關於這個專案究竟是一個「真正的」Lisp 方言，還是一個僅僅是語法包裝層，存在著一個根本性的問題。一些觀察者認為，單純將 Rust 重寫為 s-expressions 並不會創造出傳統意義上的 Lisp——這通常意味著具備同構性（homoiconicity）以及一個可以將程式碼視為數據進行操作的強大宏（macro）系統。

"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."

LLM Integration and Grammar

關於該專案與大型語言模型（LLMs）的相容性，出現了一個有趣的爭議點。一些開發者建議，s-expressions 實際上對於 AI 輔助編碼並非良策，因為 LLMs 經常在處理 Lisp 固有的深層嵌套與括號匹配時感到吃力。

建議指出，與 Algol 風格或 Pythonic 語言（LL(1) 文法）更一致的文法更有效，因為它能更好地與這些語言的大量訓練數據對齊。這顯示了人類對 Lisp 優雅性的偏好，與現代 AI 編碼代理（coding agents）的運作效率之間的緊張關係。

Conclusion: The Value of Syntactic Experimentation

雖然 "rust-but-lisp" 可能被某些人視為一種好奇心驅動的嘗試而非工具，但它突顯了關於語法與語義之間關係的更廣泛討論。透過剝離 Rust 標準的 C 風格語法，並以 s-expressions 取代，該專案迫使開發者思考語言的底層結構。

無論它是作為開發者的可行替代方案，還是僅僅作為一個小眾的實驗，它都強調了 Rust 語義的持久吸引力，以及對 Lisp 結構純粹性的持續著迷。