As implied above, this is still very preliminary: a few things work, but a lot more things don't. It's a little further along than the proof-of-concept version that was released with OpenMCL 0.11 (any funny colors you see on the screen are there intentionally this time), but there are still known bugs and lots and lots of missing features.
All of what exists so far is written in a sort of pidgin dialect of Lisp that looks a little like Objective-C. (You may have to squint a bit ...). The Objective-C runtime system is designed to allow incremental class definition and method definition/redefinition, so it's a bit easier to hook into and to do Lisp-like things in than some other environments would be. It's still a pretty low-level and unforgiving programming environment; the pidgin Lisp layer could be made more robust, but I think that most Lisp programmers would want to deal with things at a higher level. That higher level (CLOS integration, better integration of Lisp and ObjC exceptions, etc.) would have to be built on top of this lower level or something like it.
All of this is (obviously) MacOSX-specific. The GNUstep Project is trying to provide a cross-platform, opensourced version of OPENSTEP (and therefore a potentially high degree of compatibility with Cocoa.) It might therefore be possible to port some of this to GNUstep and Linux; I don't know how much would be involved in that.
I'd like to see this evolve, both to provide a richer development environment for OpenMCL and to provide a user-interface layer for delivered applications. I think that the second goal may be more important than the first, since there are already reasonable alternative (Emacs+ILISP) development environments. If this IDE reaches the point where it's not painful to use, it would probably be appropriate to start addressing that second goal.
Saving a heap image after loading the "COCOA" demo doesn't work: a lot of foreign code would have to be re-loaded and foreign data would have to be reinitialized in order for this to behave reasonably.
In fact, I've never even tried compiling the sources (via COMPILE-FILE), and wouldn't be surprized if this didn't work for some reason. It takes a few seconds to load the .lisp files; most of this time is spent opening and initializing the Foundation and AppKit frameworks. It would be good to straighten things out so that the sources could be compiled, but this hasn't been a priority.
The demo works by loading the Cocoa frameworks into the environment of a command-line tool (the regular dppccl/dppcl.image), then clobbering argv[0] to fool Cocoa into thinking that OpenMCL was launched from inside the application bundle. (There actually needs to be an empty "dppcl" file inside the bundle for this trick to work.) At some point, the kernel should be linked against the Cocoa libraries and installed as part of an application bundle; in the meantime, the lisp continues to run both as a TTY application and as a Cocoa application (with its own window layer and menubar.) That's a little weird, but can be sort of useful.
All of the sources are in the "CCL" package; they may want to be in a package or two of their own.
Loading "ccl:examples;cocoa.lisp") (via (REQUIRE
"COCOA")) loads a few other files from the examples
directory, defining some ObjC classes and methods, and
starts a Cocoa event loop running in a separate lisp thread.
The file "ccl:examples;apple-objc.lisp" defines some functions,
macros, reader-macros, and other constructs used to interact
with the Objective-C runtime. The reader macros are defined in
a separate readtable (*OBJC-READTABLE*); the other
source files generally have to arrange to use this readtable.
"apple-objc" loads the foundation framework and provides support
for dealing with and caching NSStrings, method selectors, classes,
methods, and other runtime constructs. It defines the macros
DEF-OBJC-CLASS and DEFINE-OBJC-METHOD.
It's reasonable to assume that the syntax of things defined
in "apple-objc.lisp" will change frequently and drastically for
a while yet.
The file "ccl:examples;cocoa-window.lisp" provides a definition of the method used by Cocoa's NSApplication class to poll for events. This definition uses PROCESS-WAIT; this gives other lisp threads a chance to run but does mean that more CPU cycles are expended polling for events than would be if OpenMCL's threads were scheduled by the OS.
The files "ccl:examples;cocoa-editor.lisp" and "ccl:examples;cocoa-listener.lisp" define text editor and listener document and window controller classes, respectively (listeners are subclasses of editors.) The document classes manage loading and saving files (applies more to editors, obviously) and the window controller classes load .nib files and additionally serve as "delegates" for the text-editing objects in their respective windows. In this role, they're able to customize the behavior of standard editing commands and to implement application- and class-specific commands and behavior.
After arranging to load the other files, "ccl:examples;cocoa.lisp" defines a class which serves as the global application object's delegate (and as such can intercept application-related events.) This mechanism is used to load application-specific key bindings; although Cocoa's built-in text editing class provides some Emacs-like key bindings, it doesn't provide lisp-specific bindings for navigating and selecting by expression or for operating on those selections. "cocoa.lisp" then initializes the global application object (an instance of the class "lispapplication"), sets its delegate, and invokes the application's "run" method in a separate lisp thread.
Listeners use font-change information to distinguish between user input and system output; this is intended both to make those things easier to distinguish and to simplify the implementation of history-navigation mechanisms (like C-M-P/ C-M-N in ILISP or M-G in MCL.) It should be possible to preserve this scheme and still allow the user to change fonts and colors according to preference.
One gets a lot of (generally good) editing functionality "for free" with Cocoa's NSTextView and related classes. Although the demo application gets all of that free stuff, it's clear that turning the demo application into a usable lisp editor will take some effort.
Any lisp errors (and many ObjC errors) in the Cocoa event loop are generally fatal. The lisp code could be more careful (it could check to see if an object understands a message before sending it, for instance) but there needs to be some better way of handling errors when they occur (perhaps involving -[NSApplication "stop:"] and -[NSApplication "run"]).
The real list of bugs here is a lot longer. This is arguably better than "text and menus are in funny colors on G4s and things lock up after a few seconds"; hopefully, it'll continue to stabilize and improve and the list of bugs will start to get shorter.