Aggregated response to comments

I am aggregating the responses to the comments about my first post:

About Common Lisp and Lisp in general:

I have worked on Lisp for many years, and I think it has strength that sets it apart from other dynamic languages. My favorite is the fact that you can extend the Lisp language to create your own special purpose language in a very natural way using macros. Lisp has a very simple syntax (prefix notation). As long as your extensions adhere to that syntax, it is possible to make them seamless. Arguably, CLOS is a very large extension to Common Lisp, even though you don't need *any* compiler changes to do a pretty good job implementing it on top of regular Common Lisp.

Last year, I gave a talk at the International Lisp Conference about the need for Lisp to integrate with the CLR (and / or Java). See the following URL

https://www.international-lisp-conference.org/2005/speakers.html#patrick_dussud

About JVM limitations:

Well, the JVM has technical limitations that were hard for us to solve: the JVM is designed to execute type safe languages only and we wanted to executed unsafe C++ as well. Solving this would have required the support of the entire Java community and this didn't make sense for the community at large.

Other limitation were contractual. We discovered that the compliance test suite didn't allow us to extend the existing Java classes so it was hard for us to reflect the Windows platform with more fidelity.

We also discovered that it was very hard to negociate for a different / better Java to Native code interop layer. This was both a technical and political issue: the interop layer is heavily archicture specific - it is hard to make it universal aka Run anywhere-  and it is quite visible to programmers unlike an extension library on the side.

About the rationale for our design decisions:

First and foremost, we wanted to support safe execution of type safe languages . We designed a security model to separate trusted code from untrusted code and app domains to isolate code execution contexts from each other. We also wanted to be able to recompile an existing C++ application with an extra /CLR flag and run this application under the CLR. These high level goals lead us to where we are now. We briefly thought about a small GCed runtime for C++ but because C++ isn't type safe, it wasn't that interesting to us. Also you are severely limited in the ability to manage memory automatically for a language which can "hide" references in other datatypes or even by adding extra bits to the reference and such clever tricks.

Comments

• Anonymous
  December 02, 2006
  Hi Patrick, Have you had a chance to look at Nemerle http://nemerle.org/Main_Page ? This research language became popular in our Russian community and one of the main features is it's macro subsystem. Thanks, Andrei

• Anonymous
  December 04, 2006
  It's very unfortunate you left behind your Common Lisp sources of the GC! Surely they were a great piece of code to learn from...

• Anonymous
  December 17, 2006
  The comment has been removed

• Anonymous
  January 03, 2007
  Integrating an unmanaged forth interpreter with .net: Take a look at the MSDN pages on interop. You should be able to do this on the same thread. It is more an issue of data than control flow. You need to build a layer which can pass the .net methods as delegate so your interpreter can call them back. See http://msdn2.microsoft.com/en-us/library/system.runtime.interopservices.aspx