For the past months I have spent most of my time on .NET using C# but I also would have liked to use Common Lisp on it. I do not know of a CL implementation for .NET and I read some time ago that probably doing one is not that easy, as this answer in Stack Overflow states. I wonder if it is related to floating-point exceptions (if someone knowledgeable in this area would like to comment, I thank you in advance!).
Anyway, I decided to look more carefully to see if I could find something and discovered four projects. Initially I was a bit excited that probably there is something after all. But after a more careful observation, they are far from what you would expect or want. For future reference:
The first project, ClearLisp, looked promising but it’s not even CL. Looking at the documentation you realize some differences between it and CL. Also, the project shows no sign of life since 2008 and after playing with it a little bit, it’s far from a modern CL implementation. The second one is not a proper implementation since it’s using ABCL and IKVM. The third one seems to be a way to connect ECL to .NET and uses it as a scripting language. The fourth one also looks more like an attempt than a real implementation (I didn’t explore it).
In the end, there is really no CL implementation for .NET or even one that compiles to bytecode. There is RDNZL which lets you call .NET libraries from a Common Lisp application. However, it’s not the same as having a real implementation.
Furthermore, the state of Lisp-languages on .NET is not much better since you can find lots of half-baked, abandoned languages/implementations or just without real followers (for example, L#, Yarr, dotlisp, Common Larceny, ayaka and others). The major exceptions are probably IronScheme and Clojure. And even the CLR Clojure implementation is just playing catch-up with the Java one.
The set of programmers interested in CL (or even just Lisp) and .NET is probably extremely small and thus, the current state of affairs. However, I feel that this can still be a good area of opportunity if done right.
Edit 1: zvrba on reddit explains the floats issue, which I put here:
The problem with CLR floating-point is that the virtual machine supports only one floating-point type, double (64-bit). (32-bit) float is a storage format only, so in some cases double rounding occurs, leading to results that differ from “proper” float calculations by 1 ulp.
Edit 2: clausb also on reddit pointed out to a list of Lisp projects on .NET he compiled before.
Disclaimer: the views and opinions expressed on this blog are my own and not those of my employer.
Jorge Tavares Notes 
The big question is whether you want Common Lisp and thus to fight the CLR or a new Lisp that embraces the CLR?
Designing Lisp dialects is fun, but the less standardised they become, the less users you have. (That was my L# experience). It’s a lot of work.
I think Paul Graham’s arc dialect compiling to LINQ expression trees might be a good compromise?
Hi Rob,
Thanks for your feedback! The point you make is very important and to be honest, I don’t know yet what I really would like.
On one hand, I think an implementation of CL for .NET could exist, just like ABCL for the JVM. It would allow you to use CL and have a better interop with the platform. On the other hand, a lisp language that would embrace the platform would definitely leverage it better. In this case I am thinking of something like F# (let’s call it a CL#).
But you’re right, this would involve lot of work and the hardest part is probably not even the language design but the rest. Why would an Arc dialect be a good compromise?
Arc is small enough to be an achievable project and lispy enough to be really useful. It is stable enough to be considered a “spec” and there is a reference implementation.
I think Common Lisp or Clojure would be a much larger amount of work.
If you invent a dialect, it’s never really “finished” and it’s hard to get momentum.
Thanks Rob. I also agree Clojure and CL are very large efforts. Clojure actually has a CLR implementation but I still didn’t try it. However, I would prefer something more close to CL.
Hey Jorge,
I’m Alex Muscar, one of the authors of the Gray Common Lisp project. It’s an old project that I started together with a friend of mine, and which we (obviously) didn’t finish. The fact that it’s not finished has nothing to do with .NET suitability as a platform for CL, we just didn’t have the time to finish it. I don’t think it’s a good candidate for your list since it was never meant as a serious endeavor. In retrospect the name is indeed unfortunate.
All the best,
Alex
Hi Alex,
Thanks for your comment! I mentioned your project because I wanted to list everything (at least that I came across) that was related to CL and .NET. I would be interested in hearing/learning from your experience in implementing Gray CL.
Cheers!
Hey,
Again, Gray CL is not that relevant as you can see from the source code. But I have done some other work with lisps on .NET with varying degrees of success. Most notably I’ve done a Lisp-1 with CL-like macros interpreter in F# (http://link.springer.com/chapter/10.1007%2F978-3-642-03214-1_31?LI=true)–I know, horribly unsafe because of the single namespace and non-hygienic macros, but I was young an foolish :). Being an interpreter things were relatively easy, but, as you can imagine not very efficient. The experience was painless enough. The other project was a Lisp-2, IIRC, which compiled to IL via DynamicMethods. I got it far enough to do some interesting stuff, but I didn’t get around to finishing it, and the code was quite a mess, but that was my fault, not CLR’s. The experience was, again, painless enough, and this time around it was quite fast despite using Object all over the place (not sure if dynamic was around back then, and I never liked the DLR). I imagine that, with a bit of type inference–which is not a trivial task for a dynamic language like Lisp–you can make it a lot faster. *But*, none of my Lisps featured objects. Maybe the compiled one had structures, not sure.
One of the main pain points of implementing CL on the JVM and CLR is CLOS, because the underlying object system of both platform is weaker than that of CLOS. But I think you can go a long way with implementing it in Lisp (cf. The Art of the Metaobject Protocol), even though that won’t be as fast as if it were compiled to IL or JVM bytecode. If you are willing to make a custom dialect with an object system tailored to that of the CLR than you can go on and compile it to IL. Another pain point I imagine is the numeric tower–there are some nasty problems with floats on the CLR. And finally, the condition system is again more powerful than what the CLR gives you, AFAIK, but I haven’t done any serious reading on this topic do take my comment with a grain of salt. Again, if you are willing to sacrifice some of the power of CL to make it fit better with the CLR than you can get a pretty decent Lisp with not that much work. I think Rob’s idea is quite do-able.
Thanks a lot for the feedback! You already did a lot of work when it comes to implement Lisps. Do you still use any of your Lisps or it was all just for fun? :-)
Just for fun :). Maybe someday, when I have some spare time I’ll have a go at another Lisp. It’s always great fun.
Cool :)
I started a project a while back and I just put it up on github. It is called Lunula (https://github.com/anthonyf/lunula) and it is a self-hosted Common Lisp to Javascript compiler.
So far I have written a proof-of-concept compiler (not self hosted) and now I am in the process of implementing all of the necessary Common Lisp standard functions and macros in Lisp itself using as few primitives as possible. The initial goal is to implement a small “core”, enough Common Lisp so that the compiler can be written in itself. Later I’ll add CLOS and other big CL features as additional libraries.
I still have a lot of work ahead of me to even get it working for Javascript but I have been thinking about using it as a base for compilation to other languages, including C# or CLR. Maybe it will be useful for you in the future.
Hi,
Thanks for sharing your project, it really looks interesting! Definitely I will take a look at it.