Mulling Things Over


Common Lisp in .NET

For fun and education, I’m currently working on an implementation of Common Lisp on the .NET framework. This meshes with my personal strong interest in Common Lisp, and my new responsibilities at my day job, where I’ve just become a charter member of a group that is working on a new generation of products based on the .NET framework.

Common Lisp is a big language. Even the language core, which I define loosely as the various special operators, the “most primitive” built-in data types, and the most primitive functions associated with these types, is pretty large. I don’t know how far this project will get, but it should be a fun way of learning the excruciating details of Common Lisp, the .NET framework, and C#.

So far, I’ve got a basic implementation of READTABLE and the reader functions (sufficient to read symbols, lists, strings, and fixnums), basic printing functionality (similar coverage), and a bare start on the evaluator. A simple REPL understands how to evaluate whatever can be read, but the only operators supported so far are SETQ, QUOTE, CATCH, and THROW. Everything is written in C# so far, using .NET 2.0 beta 1 but trying to stick to .NET 1.1 features for the most part. (I’ll be picking up beta 2 this week, hopefully.)

The next steps require some interesting decisions. I can stop further development of the evaluator and instead head in the direction of always-compile-to-execute, which is fairly common in modern CL implementations, AFAIK. Since compilation is an important and complex feature, and implementing it is likely to teach me quite a bit about the details of the .NET framework, I’m inclined to go in this direction.

The basic ability to dynamically compile and execute code seems well-developed in .NET, but there are some concerns. In particular, the ability to reclaim resources from dynamic assemblies seems to be sorely lacking in .NET 1.1. (See for instance this entry in Jim Arnold’s blog, and associated links.) Many people seem to be calling for the ability to unload assemblies, but even this feature would be at the wrong granularity to support a Lisp-like language efficiently, which needs to be able to define and redefine functions. If function code memory is never released, this could be a terrible waste of resources, especially when implementing dynamically-created closures as compiled code.

There is hope for 2.0, though. This article on Jason Zander’s blog discusses “Lightweight Code Generation” and methods that are garbage-collectable. It references examples in
this article on Joel Pobar’s blog. I’m still digesting the information in these blogs.

The code for this project is not publicly available at this time.

One Response to “Common Lisp in .NET”

  1. 1 » Blog Archive » CLinNET -> RDNZL -> CL-CLR Says:

    […] I haven’t worked on CLinNet in quite a while, but a few months ago I started playing with RDNZL, a .NET/Common Lisp interface written by Edi Weitz. Very nice! But I had some problems with type lookup in RDNZL when I tried using it to work with Direct3D. I discussed some of them with Edi on the RDNZL developer’s mailing list, and figured out a fix. But then I got interested in changing the way some other things in RDNZL worked, so I ended up writing a layer on top of it to experiment with. I call it CL-CLR. […]

Leave a Reply

© 2021 Mulling Things Over | Entries (RSS) and Comments (RSS)

Design by Web4 Sudoku - Powered By Wordpress