On the openmcl-devel mailing list there's a discussion about how to create a nice interface to OS X's Cocoa framework from within OpenMCL, motivated primarily by the desire to make it easy to develop nice Aqua GUIs.
Objective C is interesting because there's a lot of introspection that can be done at runtime--you can determine the class of an object, the methods it supports, etc., which makes it at least seem possible to create a very general interface that doesn't have to have hardcoded support for each Objective C class and method. Such an interface has already been developed for Python, the PyObjC bridge.
Gary Byers discusses a couple approaches to bridging the gap between Objective C objects and Lisp objects:
Posted by jjwiseman at May 15, 2003 10:48 AMI want to try to keep this reply high-level and abstract, but can't resist the temptation to sink into the gutter (or at least some lower- level details) for a moment. I don't know if anyone's ever looked at the function OBCJ-OBJECT-P (in “ccl:examples;apple-objc.lisp”); it does a very, very good job of heuristically determining whether or not a given MACPTR is an ObjC object (and if so, whether it's an instance, class, or metaclass object and what its class is.) One might be able to artificially construct a MACPTR that passed these heuristic tests, but such a MACPTR would have to look so much like an ObjC object that the ObjC runtime would be fooled as well; for the sake of argument, anything that OBJC-OBJECT-P says is an ObjC object pretty much -is- an ObjC object. (If anyone's skeptical about this, note that it's also possible to make OBJC-OBJECT-P more paranoid than it currently is. If we don't want to make this (as) heuristic, we can also modify the FFI to -really- distinguish between :ADDRESS (arbitrary pointer) and :ID (pointer to ObjC object, or - perhaps more generally - "pointer to runtime-typed foreign object", which might also provide a way to deal with CFObjects.)
Suppose that CLASS-OF and TYPE-OF (and a few other things) knew (via OBJC-OBJECT-P) that the result of calling
[[(@class “NSWindow”) “alloc”] “initWithContentRect:...”]was an instance of the NSWINDOW class (in the CLOS sense as well as the ObjC sense.) In such a world, the result of doing:
(make-instance 'nswindow :content-rect ...)would be the same type of object (and interchangably recognizable as an NSWINDOW/:<NSW>indow instance to both ObjC and CLOS.)
[...]
I have to admit that I find the unified approach attractive, if only because in every book or movie I've ever read or seen that involves Parallel Universes, something bad invariably happens.