Conexión de .NET a Common Lisp

Question

Tengo un módulo LispWorks Common Lisp bastante complicado que se encuentra sobre algunos módulos .NET a través de RDNZL.

Ha surgido que necesito exponer algunas de sus funcionalidades a algunas otras aplicaciones .NET, y no estoy seguro de la mejor (más corta) forma de abordar esto sin volver a escribir el módulo en C#. Sé que hay algunas implementaciones de CLR Lisp, pero la mayoría parecen no estar completas o son mantenidas y hay muchas cosas que no se pueden volver a escribir trivialmente en Scheme.

¿Hay alguna instalación que exponga lo contrario de lo que habilita RDNZL (.NET -> Common Lisp)? ¿Puedo usar RDNZL para entregar un archivo DLL que acepte objetos .NET?

---

estoy editando esto para incluir algunas de las opciones que la mayor parte con un interés en Lisp es probable que saber acerca de si están en Windows, y por qué no acabo de cumplir con los requisitos anteriores (o cómo, al igual sus usuarios, no transmití adecuadamente mis requisitos :).

• IronScheme - Niza, rápido, mantiene y rápido pero no es Common Lisp
• ClojureCLR - Lisp no es común; Beta, toma ~ 4secs para mí para poner en marcha (aceptable para aplicaciones de larga duración, no para cosas que requieren instancias frescas y luego unas pocas docenas de llamadas)
• LSharp - Lisp no es común, no se mantiene
• RDNZL - Permite registrando CL delegados de devolución de llamada con código .NET, pero tienes que comenzar en CL, no hay una manera relativamente simple (que yo haya podido averiguar hasta ahora) de pasar objetos .NET a una "C DLL" creada por tu Común Implementación de Lisp de elección.
• Yarr - Construido encima de LSharp (incluye defmacro y algunas otras necesidades). Parece no mantenido durante algún tiempo, pero puede ser la mejor opción por el momento.

Answer 1

"Ha llegado que necesito para exponer algunas de sus funciones a algunos otras aplicaciones .NET"

La siguiente no es exactamente lo que estás pidiendo, pero si quiere pensar por un momento, creo que quizás usar mensajes sería más fácil (esto se basa completamente en la declaración citada anteriormente). Algo así como ZeroMQ, que tiene enlaces tanto para Common Lisp como para .Net. Entonces no se trataría de cómo reescribir un módulo para hacerlo compatible con .Net, sino de cómo integrar los mensajes en el módulo para que una aplicación .Net independiente lo consuma. Ambos lados de la conversación tendrían que estar de acuerdo con el formato de mensaje, pero en mi opinión es más fácil que la ruta que consideras en tu publicación.

Si tiene que hacer más de una aplicación, quizás una arquitectura de pub/sub se adapte a sus necesidades.

Answer 2

Usted puede encontrar LSharp de algún interés LSharp También hay Iron Scheme También existe Xronos, que atraparán dice ser un dialecto de Lisp.

Me gustaría pasar un poco de tiempo investigando qué tan difícil sería para transportar su código a F #, con la limitación y las diferencias que langage tiene sobre Lisp. Ciertamente hay algunas construcciones en Lisp, que me resultaría difícil presionar con elegancia en F #.