compiled open source Windows lisp (was Re: Python becoming less Lisp-like)

[Carl Shapiro]

"Brandon J. Van Every" <try_vanevery_at_mycompanyname at yahoo.com> 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.