views:

192

answers:

2

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.
+4  A: 

"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.

Shaun
Well, I agree that this would probably be easier for this particular instance, but I think that it would be a very positive thing for CL-ers to have the option of using their code largely as is.Also, the CL wrapper for that is released under the LGPL which is generally [frowned upon](http://common-lisp.net/faq.shtml#lgpl) in favor of the [LLGPL](http://opensource.franz.com/). I may contact the author about that.
JPanest
And, to actually address your suggestion, the biggest turn-off with this approach is that it introduces seemingly unnecessary effort for smaller programs and modules, and requires maintenance and monitoring of two applications.
JPanest
Well, its only something to think about. Certainly you'll find the best approach that works for you. I only brought it up cause 1: it sounds like you'll have multiple apps anyway and 2: its easier from my own experience to have small, highly specialized apps that talk through messages than to have large apps/modules that try to be all things for all consumers. That and I personally hate porting code (like the clojure suggestion), so this is the kind of mental toolset I tend to reach for. YMMV.
Shaun
I definitely appreciate the suggestion. I reached out to the developer about the license and will likely find a purpose for this whether or not it is for this specific case. Thank you.
JPanest
A: 

You might find LSharp of some interest LSharp There is also Iron Scheme There is also Xronos, whihc claims to be a Lisp Dialect.

I would spend a little bit of time looking into how hard it would be to port your code over to F#, with the limitation and differences that langage has over Lisp. There are certainly quite a few constructs in Lisp, that I would find hard to elegantly press into F#.

Development 4.0
Yes, I picked up several books on F# for other reasons recently. The current system makes fairly heavy use of macros and exposes a few related DSLs that would be difficult to express (or, at the very least rewrite) in a non-Lisp.
JPanest
Xronos looks interesting but it seems stuck at 0.1 with no commits in 7 months and no mailing list posts in 13. Thank you for pointing it out to me, I hadn't seen it before.
JPanest