将.NET连接到通用Lisp

Question

我有一个相当复杂的LispWorks Common Lisp模块，通过RDNZL连接到一些.NET模块上。

现在需要将其部分功能暴露给其他.NET应用程序，但我不确定在不重写C#模块的情况下处理这个问题的最佳（最短）方法。我知道有几个CLR Lisp实现，但大多数似乎未维护或不完整，并且有许多东西无法轻松地在Scheme中重写。

是否有任何机制可以公开与RDNZL相反的功能（.NET -> Common Lisp）？我可以使用RDNZL提供接受.NET对象的DLL吗？

---

我正在编辑此内容，以包含大多数对Lisp感兴趣的Windows用户可能会知道的选项，以及它们为什么不完全符合上述要求（或者像您的用户一样，我没有充分传达我的需求:）。

• IronScheme-不错、快速、经过维护和快速，但不是Common Lisp。
• ClojureCLR-不是Common Lisp；Beta版，在我这里启动需要约4秒钟（对于长时间运行的应用程序可接受，但对于需要新实例化然后进行几十次调用的应用，不太适用）。
• LSharp-不是Common Lisp，也没有得到维护。
• RDNZL-允许在.NET代码中注册CL回调委托，但您必须从CL开始，而且没有比较简单的方法（迄今为止我还没有能够找出）将.NET对象传递到由您选择的Common Lisp实现创建的“C DLL"。
• Yarr-建立在LSharp之上（包括defmacro和其他一些必需品）。看起来已经有一段时间未得到维护，但可能是目前最好的选择。

- JPanest

---

也许你可以将你的CL代码移植到Clojure并使用clojure-clr？ - Michiel Borkent

Answer 1

以下并不是您要求的内容，但如果您想要稍微冷静思考一下，我认为可能使用消息传递会更容易（这完全基于上面引用的声明）。例如ZeroMQ，它既有Common Lisp的绑定，也有.Net的绑定。然后问题就不在于如何重写模块使其与.Net兼容，而在于如何将消息传递集成到模块中，以便独立的.Net应用程序可以消费它。对话的双方都必须同意消息格式，但在我看来，这比您在帖子中考虑的路线更容易。 如果您需要将其变成多个应用程序，则发布/订阅架构可能适合您的需求。

- Shaun

---

我同意对于这个特定实例来说，这可能更容易，但我认为让CL用户有使用其代码的选项是非常积极的事情。此外，该CL包装器发布在LGPL下，这通常不如LLGPL受欢迎。我可以联系作者了解详情。 - JPanest

实际上，针对您的建议，这种方法最大的缺点是对于较小的程序和模块引入了看似不必要的工作，并且需要维护和监控两个应用程序。 - JPanest

嗯，这只是一个值得思考的问题。当然，你会找到最适合你的最佳方法。我提出来的原因只是因为1：听起来你可能会有多个应用程序，2：从我的经验来看，拥有通过消息交流的小型高度专业化的应用程序要比尝试成为所有消费者所需的一切的大型应用程序/模块更容易。而且，我个人讨厌移植代码（比如clojure建议），所以这是我倾向于使用的一种思维工具。但你的情况可能不同。 - Shaun

我非常感谢您的建议。我已经联系了开发人员关于许可证的问题，无论是否适用于这种特定情况，我都可能会找到一个用途。谢谢。 - JPanest

Answer 2

你可能会对LSharp感兴趣LSharp 还有Iron Scheme 还有Xronos，它声称是一种Lisp方言。

我建议你花点时间研究一下将代码移植到F#的难度，以及这种语言与Lisp之间的限制和差异。在Lisp中，肯定有很多构造方式，我觉得很难优雅地转换到F#中。

- Development 4.0

---

是的，最近我因为其他原因买了几本关于F#的书。当前系统相当重度使用宏，并公开了一些相关DSL，这些在非Lisp语言中很难表达（或者至少需要重写）。 - JPanest

Xronos看起来很有趣，但似乎已经停滞在0.1版本，7个月没有任何提交，13天没有邮件列表的帖子。谢谢您向我指出它，我之前还没有看过。 - JPanest