"Brandon J. Van Every" <[EMAIL PROTECTED]> writes: > Last I looked, 2 years ago?, there were no compiled, open source lisps that > ran on Windows. Has this changed?
I have a virtually completed port of CMUCL to Win32. And, if I was not busy organizing a Lisp conference, it would be publicly available by now. An observation: most of the open-source Lisp implementations make egregious assumptions about the underlying operating system, most of which are just barely valid, even on UNIX. (Perhaps this is an observation about UNIX software in general.) A lot of this had to be untangled in order to make CMUCL usable. More work remains to be done. When playing the role of a Windows developer, I have never been satisfied with the level of integration that language run-times with a UNIX heritage has to the Win32 API. Such things as file system interaction, I/O completion ports, thread pools, componentized software, synchronization primitives and the like never quite work correctly, especially when there is a run-time library which sits above the C library. You will find an amazing amount of shennanigans in Lisp run-time libraries (commercial and open-source) as well as those belonging to the various strongly-typed functional languages, and scripting languages. These systems would appear to have been written with the assumption that they would be the "harness" of an application, and that UNIX compatibility was an overriding concern; fatal flaws for Win32 development. I have never been a game developer, but I have worked on real-time systems--written in Lisp. I would guess that programmers in both these domains have similar concerns. You can write continuous systems in Lisp, but it requires a fair amount of wizardry. (This is basically true of most garbage collected systems.) Real-time collectors help but often sap performance and introduce constraints of their own. -- http://mail.python.org/mailman/listinfo/python-list
