Alternatively, it might be possible to (ab)use the delegate support in RDNZL to get what you need - simply define the delegate signatures you require in an interface class on the C# side, then use RDNZL to create an interface object and attach lisp closures (I do something like this to implement LISP callbacks for a somewhat misdesigned .NET library). It might even be possible to generate some sort of reverse RDNZL this way :-)
Alternatively, create some sort of RPC interface for your LISP code.
On Apr 22, 2010, at 19:58 , Edi Weitz wrote:
What I know is that for example LispWorks can deliver Lisp DLLs which look like C DLLs (with the corresponding entry points) from the outside. Maybe there's a way to "wrap" such a "C DLL" so that it can be used from .NET?
Just a wild thought, Edi.
On Thu, Apr 22, 2010 at 5:54 PM, Joerthan Panest joerthan.panest@gmail.com wrote:
My familiarity with .NET in this regard is fairly limited, but I was wondering what would be required to expose modules written in Common Lisp on top of .NET to other .NET modules.
I'm afraid the answer might be some CLR Lisp implementation, of which there are few (if any) that are very mature that I know of.
Basically, I have a fairly involved (LispWorks) Common Lisp module that was originally the entry point for a number of applications, which itself made calls to .NET components. The requirement has come up that I expose some of it's features to a .NET application and I'd like to avoid reimplementing all of it in C#.
I'm not sure this is even an RDNZL question, but given that is my starting point I cannot help but wonder whether people have encountered the same issue given the nature of the problem RDNZL is solving.
rdnzl-devel mailing list rdnzl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/rdnzl-devel
rdnzl-devel mailing list rdnzl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/rdnzl-devel