Connessione a .NET Lisp

Question

Ho un modulo Lisp LispWorks Common Lisp che si trova su alcuni moduli .NET tramite RDNZL.

È venuto fuori che ho bisogno di esporre alcune delle sue funzionalità ad alcune altre applicazioni .NET, e non sono sicuro il modo migliore (più breve) per avvicinarsi a questo senza riscrivere il modulo in C#. So che ci sono alcune implementazioni di LIS CLR, ma la maggior parte sembra non mantenuta o incompleta e ci sono molte cose che non possono essere banalmente riscritte in Scheme.

C'è qualche funzione che espone il contrario di ciò che RDNZL abilita (. NET -> Common Lisp)? Posso usare RDNZL per consegnare una DLL che accetta oggetti .NET?

---

sto modificando questo per includere alcune opzioni che la maggior parte con un interesse in Lisp sarà probabilmente conoscere se sono su Windows, e perché non abbastanza soddisfare i requisiti di cui sopra (o come, come i tuoi utenti, non ho trasmesso adeguatamente le mie richieste :).

• IronScheme - Nizza, veloce, mantenuto e veloce, ma non è Common Lisp
• ClojureCLR - Lisp non comune; Beta, prende ~ 4secs per me per avviare (accettabile per applicazioni di lunga durata, non per cose che richiedono istanze fresca e poi a poche decine di chiamate)
• LSharp - Lisp non è comune, non sia mantenuto
• rdnzl - Permette di registrando i delegati di callback CL con codice .NET, ma è necessario iniziare in CL, non esiste un modo relativamente semplice (che sono stato in grado di capire fino ad ora) per passare gli oggetti .NET in una "DLL C" creata dal tuo Common Lisp implementazione della scelta.
• Yarr - Costruito sopra LSharp (include defmacro e alcuni altri need-to-have). Sembra non mantenuto per un po 'di tempo, ma potrebbe essere l'opzione migliore per il momento.

Answer 1

"è venuto su che ho bisogno di esporre alcune delle sue funzionalità per alcune altre applicazioni .NET"

La seguente non è esattamente quello che stai chiedendo, ma se vuoi pensare fuori dagli schemi per un momento, penso che forse usare la messaggistica sarebbe più facile (questo si basa interamente sulla dichiarazione citata sopra). Qualcosa come ZeroMQ, che ha binding sia per Common Lisp che per .Net. Quindi non sarebbe una questione di come riscrivere un modulo per renderlo compatibile con .Net, ma come integrare la messaggistica nel modulo per un'app .Net indipendente per consumarlo. Entrambi i lati della conversazione dovrebbero essere d'accordo sul formato della messaggistica, ma nella mia mente è più facile della rotta che consideri nel tuo post.

Se è necessario renderlo più di un'applicazione, forse un'architettura pub/sotto si adatta alle proprie esigenze.

Answer 2

Si potrebbe trovare LSharp di un certo interesse LSharp C'è anche Iron Scheme C'è anche Xronos, fattore di forte afferma di essere un Lisp dialetto.

Passerei un po 'di tempo a esaminare quanto sarebbe stato difficile portare il codice su F #, con le limitazioni e le differenze che il langage ha su Lisp. Ci sono certamente alcuni costrutti in Lisp, che troverei difficile premere elegantemente in F #.