Zach Beane (xach) wrote,

Corman Lisp may go open source

Last month I emailed Roger Corman about his future plans for Corman Common Lisp. Here's his response:

Hi Zach,
Thanks for your interest in Corman Lisp. I have been unable to commit any resources to developing Corman Lisp for the last couple of years. I would be willing to convert it to open source, and let others take it over, as I don't expect to be able to get back to it any time soon. My medical software business consumes most of my time these days. The source code is all already included (at least for Corman Lisp itself). The source code for the IDE is not included, and I could package it up and add it to the distribution. Then I guess the thing would be modifying the licensing terms to reflect one of the open source models.

I see two primary issues at this point. First, the Corman Lisp kernel needs to be built with Visual Studio 2005, which is an old version of VS. At one point I built it with VS2008 and it built and ran, but some problem with the FFI caused applications saved, and the IDE, to have problems. This type of thing is fairly common as Microsoft makes subtle changes to the code generation of their C compiler, which in turn affects the Lisp kernel which has very tight rules about how it expects its code to look. I did a lot to reduce the kernel (move things from the kernel to Lisp code, which is then compiled safely), but did not fully resolve the VS 2008 issues. Now there is VS 2010 and 2012, and I never tried building with either of those. In general I find each newer version of VS is worse for native C/C++ debugging, as .NET has become Microsoft's primary platform for new software.

The other issue is running on 64-bit OS. Again, the FFI misbehaves when you have saved an application, or just doing a bunch of FFI stuff in an application. It is something to do with GC and the 64-bit support for running 32-bit applications (which is what CL is). It could be related to the same issue as I encountered with building under VS2008.

Tracking down this problem is difficult.

Regarding converting to a full 64-bit Lisp, this would be a much bigger effort. Corman Lisp gets such good performance by a large amount of hand-optimized x86 assembly code. This would all have to be rewritten/replaced in a 64-bit Lisp.

When Corman Lisp was first developed in the late 90s, there was really no competition on Windows platforms. Franz only had a 16-bit Lisp they were selling, and not really taking the Windows market seriously. Mac Common Lisp was on 680x0 and later PowerPC but didn't get to Windows for a very long time, and LispWorks didn't support Windows until much later. Now I think most all of those have good implementations on Windows (though only MCL is free). I have used Allegro extensively for a large contract with SRI and I see the value of a mature cross-platform system like they have. It is however extremely expensive, and developing applications for distribution requires lots of negotiation and per-license payments to Franz. Corman Lisp still has some advantages, I think--it is really a good hackers Lisp, when you want to easily get down into the assembly level, or in the guts of the compiler, to do almost anything. You have the power of Lisp to do those things with macros and a nice high-level dynamic environment.

I definitely want to see it live on, so am open to whatever enables that. I don't currently derive any significant income from it so that's not a concern for me.

Roger

I can't wait to see how this goes!

Tags: lisp
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded  

  • 1 comment