Connecting .NET to Common Lisp

Question

I have a fairly involved LispWorks Common Lisp module that sits atop some .NET modules via RDNZL.

It has come up that I need to expose some of its functionality to some other .NET applications, and I'm not sure the best (shortest) way to approach this without re-writing the module in C#. I know there are a few CLR Lisp implementations but most seem unmaintained or incomplete and there are many things that cannot be trivially re-written in Scheme.

Is there any facility that exposes the opposite of what RDNZL enables (.NET -> Common Lisp)? Can I use RDNZL to deliver a DLL that accepts .NET objects?

---

I'm editing this to include some options that most with an interest in Lisp will likely know about if they're on Windows, and why they don't quite meet the requirements above (or how, like your users, I didn't adequately convey my requirements :).

• IronScheme - Nice, fast, maintained and fast but it's not Common Lisp
• ClojureCLR - Not Common Lisp; Beta, takes ~4secs for me to start up (acceptable for long-running applications, not for things that require fresh instantiations and then a few dozen calls)
• LSharp - Not Common Lisp, not maintained
• RDNZL - Allows for registering CL callback delegates with .NET code, but you have to start in CL, there is no relatively simple way (that I have been able to figure out thus far) to pass .NET objects into a "C DLL" created by your Common Lisp implementation of choice.
• Yarr - Built on top of LSharp (includes defmacro and some other need-to-haves). Looks unmaintained for some time but may be the best option for the time being.

Answer 1

"It has come up that I need to expose some of its functionality to some other .NET applications"

The following isn't exactly what you're asking for, but if you want to think out of the box for a moment, I think that perhaps using messaging would be easiest (this based entirely on the statement quoted above). Something like ZeroMQ, which has bindings for both Common Lisp as well as .Net. Then it wouldn't be a question of how to rewrite a module to make it .Net compatible, but how to integrate messaging into the module for an independent .Net app to consume it. Both sides of the conversation would have to agree on the messaging format, but in my mind that's easier than the route you consider in your post.

If you have to make it more than one application, perhaps a pub/sub architecture would fit your need.