Verbinden von .NET mit Common Lisp

8

Ich habe ein ziemlich involviertes LispWorks Common Lisp Modul, das auf einigen .NET Modulen über RDNZL sitzt.

Es ist aufgetaucht, dass ich einige seiner Funktionalität einigen anderen .NET-Anwendungen zur Verfügung stellen muss, und ich bin mir nicht sicher, der beste (kürzeste) Weg, um dies zu erreichen, ohne das Modul in C # neu zu schreiben. Ich weiß, dass es einige CLR-Lisp-Implementierungen gibt, aber die meisten scheinen nicht gepflegt oder unvollständig zu sein, und es gibt viele Dinge, die nicht einfach in Schema umgeschrieben werden können.

Gibt es eine Möglichkeit, die das Gegenteil von dem, was RDNZL ermöglicht, verfügbar macht (.NET - & gt; Common Lisp)? Kann ich RDNZL verwenden, um eine DLL zu liefern, die .NET-Objekte akzeptiert?

Ich bearbeite dies, um einige Optionen einzubeziehen, von denen die meisten, die an Lisp interessiert sind, wahrscheinlich wissen, ob sie unter Windows sind und warum sie die obigen Anforderungen nicht ganz erfüllen (oder wie, wie Ihre Benutzer, ich hat meine Anforderungen nicht ausreichend vermittelt:).

  • IronScheme - Schön, schnell, gepflegt und schnell, aber es ist nicht Common Lisp
  • ClojureCLR - Nicht allgemeines Lisp; Beta, dauert ~ 4 Sekunden für mich zu starten (akzeptabel für lang laufende Anwendungen, nicht für Dinge, die neue Instanziierungen und dann ein paar Dutzend Anrufe erfordern)
  • LSharp - Nicht gemeinsame Lisp, nicht gepflegt
  • RDNZL - Erlaubt das Registrieren von CL-Callback-Delegaten mit .NET-Code, aber Sie müssen in CL starten, es gibt keine relativ einfache Möglichkeit (die ich bis jetzt herausfinden konnte), .NET-Objekte in eine " C DLL "erstellt von Ihrer Common Lisp-Implementierung der Wahl.
  • Yarr - Errichtet auf LSharp (enthält defmacro und einige andere brauchen zu haben). Sieht für einige Zeit nicht gepflegt aus, ist aber möglicherweise die beste Option.
JPanest 22.04.2010, 16:03
quelle

2 Antworten

5
  

"Es ist aufgetaucht, dass ich entlarven muss   einige seiner Funktionen zu einigen   andere .NET-Anwendungen "

Das folgende ist nicht genau das, wonach Sie fragen, aber wenn Sie für einen Moment aus der Box heraus denken wollen, denke ich, dass die Verwendung von Messaging am einfachsten wäre (dies basiert vollständig auf der oben zitierten Aussage). Etwas wie ZeroMQ , das sowohl für Common Lisp als auch für .Net Bindings enthält. Dann wäre es nicht eine Frage, wie man ein Modul neu schreibt, um es .Net-kompatibel zu machen, sondern wie man Messaging in das Modul integriert, damit eine unabhängige .Net-App es konsumieren kann. Beide Seiten der Konversation müssten sich auf das Messaging-Format einigen, aber in meinen Augen ist das einfacher als die Route, die Sie in Ihrem Beitrag berücksichtigen.

Wenn Sie mehr als eine Anwendung erstellen müssen, passt möglicherweise eine Pub / Sub-Architektur zu Ihrem Bedarf.

    
Shaun 23.04.2010, 12:49
quelle
0

Du könntest LSharp von Interesse finden, LSharp Es gibt auch ein Eisenschema Es gibt auch Xronos , das behauptet, ein Lisp-Dialekt zu sein.

Ich würde ein bisschen Zeit damit verbringen, herauszufinden, wie schwer es wäre um Ihren Code auf F # zu portieren, mit der Einschränkung und den Unterschieden langage hat über Lisp. Es gibt sicherlich einige Konstrukte in Lisp, das würde ich schwer finden, elegant in F # zu drücken.

    
Development 4.0 23.04.2010 16:30
quelle

Tags und Links