对于.Net CLR是否有相当成熟的Lisp/Scheme/Clojure编译器？

我看到了几个变种；ClojureCLR、LSharp、IronScheme、IronLisp等。是否有任何这些积极维护和/或接近“成熟”的地方，或者它们大多是实验或集尘器？对于编译为.Net dll并引用其他.Net dll（如果有的话），哪一个被认为是最成熟的框架？是否有任何与Visual Studio a很好的集成，至少有一个“创建Lisp项目”功能？

IronLisp已经过时，并被IronScheme取代，而IronScheme仍然是测试版

L Sharp和ClojureCLR是相似的，它们遵循现代Lisp for CLR的相同思想（与IronScheme相反，后者试图在新平台上实现R6RS标准）。ClojureCr似乎比L Sharp更受欢迎，Java的Clojure社区正在迅速成长，因此您可以在.NET应用程序中使用它的许多库

我知道ClojureCLR有一个可用的

我相信，ClojureCLR现在是开发最密集的，所以我敢打赌。另一方面，Clojure（以及ClojureCLR）仍然在变化，它的未来版本可能与当前状态有很大不同，这对于长期的生产项目来说不是很好。从这一点来看，实现旧的已验证R6R的IronScheme更可取。我不能说太多L#，但我猜它介于ClojureCLR和IronScheme之间

所以，实际的决定取决于你们的个人需求：稳定性，一个（潜在）项目的规模，当然还有语言特性——别忘了学习这三个方面

有一个用于.NET的（非标准）Lisp编译器，重点是.NET互操作性：

---

它是所有列表中功能最丰富的，但它不断变化，仍处于测试阶段。

别忘了，这是一个著名的C和Java VM的Scheme编译器，最近添加了一个实验性的.NET字节码编译器。

如果您只需要从Lisp调用.NET，而不需要创建DLL's1，可能适合您

1我并不是说你不能用RDNZL和你的Lisp实现创建DLL，我只是没有任何理由尝试这么做

CloJureCLR，也不是CloSureCLR。J代表Java。请更正。那么，IronScheme、L#、ClojureCLR或其他更成熟和/或更活跃的方案？i、 例如，如果一个人喜欢括号和.Net，那么应该从哪里开始？“实验性”并不完全符合OP特别要求的“成熟”的条件。