.Net CLR 有相当成熟的 Lisp/Scheme/Clojure 编译器吗?

发布于 2024-10-07 14:02:15 字数 184 浏览 1 评论 0原文

我看到了几种变体; ClojureCLR、LSharp、IronScheme、IronLisp 等。这些是否都得到积极维护和/或接近“成熟”,或者它们主要是实验或集尘器?哪一个被认为是编译为 .Net dll 并引用其他 .Net dll(如果有)最成熟的框架?是否可以与 Visual Studio 很好地集成,至少有一个“创建 Lisp 项目”功能?

I am seeing several variants out there; ClojureCLR, LSharp, IronScheme, IronLisp, among others. Are any of these actively maintained and/or anywhere close to "mature", or are they mostly experiments or dust-gatherers? Which would be considered the most mature framework for compiling to .Net dll's and referencing other .Net dll's, if any? Does any integrate well with Visual Studio a la at least a "Create Lisp Project" feature?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

那片花海 2024-10-14 14:02:15

IronLisp 已经消亡并被 IronScheme 取代,而后者仍处于测试阶段。

L Sharp 和 ClojureCLR 很相似,并且它们遵循现代 Lisp for CLR 的相同理念(与 IronScheme 不同,IronScheme 试图在新平台上实现 R6RS 标准)。 ClojureCLR 似乎比 L Sharp 更流行,而且 Java 的 Clojure 社区正在快速成长,因此您可以在 .NET 应用程序中使用它的许多库。

我知道对于 ClojureCLR 有一个 VS2010 插件 可用。

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

因此,实际的决定取决于您的个人需求:稳定性、(潜在)项目的规模,当然还有语言功能 - 不要忘记了解所有这三个方面的知识。

IronLisp is dead and superseded by IronScheme, which in turn is still beta.

L Sharp and ClojureCLR are similar and they follow same idea of modern Lisp for CLR (in contrast to IronScheme, which tries to just implement the R6RS standard on the new platform). ClojureCLR seems to be more popular than L Sharp, and Java's Clojure community is growing up quickly, so you can use many of its libraries in your .NET application.

I know that for ClojureCLR there is a VS2010 plugin available.

I believe, ClojureCLR now is the most intensively developed, so I would bet on it. On other hand, Clojure (and so ClojureCLR) still changes, and future versions of it may differ a lot from current state, which is not very good for long term production project. From this point IronScheme, which implements old verified R6RS, is more preferable. I can't say a lot of L#, but I guess it is somewhere between ClojureCLR and IronScheme.

So, actual decision depends on your personal needs: stability, size of a (potential) project, and, of course, language features - don't forget to learn a bit about all of three.

零度℉ 2024-10-14 14:02:15

有一个适用于 .NET 的(非标准)Lisp 编译器,重点是 .NET 互操作性:

http: //www.meta-alternative.net/mbase.html

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

There is one (non-standard) Lisp compiler for .NET with an emphasis on .NET interoperability:

http://www.meta-alternative.net/mbase.html

It's the most feature-rich of all the listed, but it keeps changing and it's still in beta stage.

丶视觉 2024-10-14 14:02:15

不要忘记 Bigloo,它是一个著名的 C 模式编译器和 Java VM,最近还添加了一个实验性的 .NET 字节码编译器。

Don't forget Bigloo, which is a well-known Scheme compiler to C and the Java VM, and recently added an experimental .NET bytecode compiler.

时光清浅 2024-10-14 14:02:15

如果您只需要从 Lisp 调用 .NET,并且不需要创建 DLL 的1RDNZL 可能适合您。

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

If you just need to call .NET from Lisp, and you don't need to create DLL's1, RDNZL may work for you.

1I'm not saying that you can't create DLL's with RDNZL and your Lisp implementation, I just haven't had any reason to try to do it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文