[Openmcl-devel] Using Cocoa with MCL
beer at eecs.cwru.edu
Thu May 8 14:56:24 EDT 2003
> I would like (for lots of reasons) to make it into something that
> could use to do actual work, and to improve the interoperability
> OpenMCL and Cocoa so that people could more easily develop real
> with rich GUIs.
> I've occasionally heard other people mention that they're working
> on some aspects of improving and extending the Cocoa support, and
> there have been some suggestions made on this list for making the
> business of writing Cocoa programs in OpenMCL a less tedious and
> error-prone process than it currently is.
Since I'm one of the people who expressed an interest in this a few
months ago, I felt compelled (shamed?) into replying.
There are a number of technical issues that need to be worked out in
order to better integrate Cocoa into Lisp. But I think a prior
question is What kind of Lisp interface would be necessary for more
people to start doing serious GUI development in OpenMCL? There are
some obvious things, but beyond these there are genuine design choices.
For example, what level of access to Cocoa should be provided in Lisp?
At one extreme, there is fairly direct access to ObjC classes, objects
and methods. Gary has basically already provided this, although
certain ObjC details (like memory management, type checking, and
conversion between Lisp data and ObjC data) could probably be hidden,
and a bit more syntactic sugar could probably be provided. This has a
number of advantages: (1) It is very lightweight; (2) It corresponds
rather directly to ObjC programming, so that, for example, examples
from Cocoa programming books could be fairly directly translated; (3)
It will automatically track any changes and improvements that Apple
makes to Cocoa. On the other hand, it feels much more like foreign
function programming than it does Lisp programming, with constant
switching between Lisp and ObjC views of the world.
At the other extreme, ObjC could be hidden completely and a CLOS
interface like the GUI classes in MCL could be implemented on top of
Cocoa. This has the advantage of being very Lisp-like, but the
disadvantages that it will require a lot more work, the direct
correspondence with Cocoa is lost and tracking Cocoa changes will
require a continuing implementation effort on the CLOS interface.
Of course, there are various options between these two extremes. One
could imagine a CLOS hierarchy that parallels the Cocoa hierarchy, with
behind-the-scenes glue code that keeps the two worlds in sync.
Technical issues aside, there are many design issues with how to
accomplish such an integration as smoothly as possible. For example,
do we want to write
styleMask: NSTitledWindowMask | NSClosableWindowMask |
[w setTitle: @"My Window"]
as (essentially Gary's current code)
[[(@class "NSWindow") "alloc"]
[w "setTitle:" @"My Window"]
or (with a special reader for #\[, with NSWindow a CLOS class )
styleMask: (bit-ior NSTitledWindowMask
[w setTitle: "My Window"]
or (a fairly direct Lispification of the ObjC names and method
(send w :set-title "My Window")
or (a major Lispification of the ObjC names and method structure)
(make-instance 'ns-window :content-rect graphicsRect)
(set-title w "My Window")
Each of these has different different implications for the "feel" of
What do people think? What is the minimum GUI level it would take to
get people to, say, write a full-featured GUI editor or debugger for
OpenMCL? What kind of a Cocoa interface would make porting CLIM to
OpenMCL easier? Hamilton Link's inspector? Cocoa applications that
people would like to port to or develop in Lisp?
Openmcl-devel mailing list
Openmcl-devel at clozure.com
More information about the Openmcl-devel