[Openmcl-devel] What is the state of the phemlock included with OpenMCL?
mikel at evins.net
Sun Aug 1 16:24:27 PDT 2004
On Aug 1, 2004, at 3:45 PM, Hamilton Link wrote:
>> May I ask why Cocoa was chosen over Carbon?
> From a possibly mistaken point of view, it seems like Cocoa is where
> OS X is going, and Carbon is where OS X came from -- in other words,
> even though Carbon isn't officially deprecated it seems like Carbon
> libraries are there mostly for backwards compatibility, new
> development in Cocoa is encouraged by Apple, that's where it new APIs
> appear, that's where several non-Carbon widgets and frameworks are,
> I think another reason for using Cocoa is that with the Cocoa bridge
> the OO API of Cocoa is (supposed to be) easier to extend and invoke
> than Carbon. C use is straight FFI calls, while ObjC use is easier to
> make look like just more lisp.
> I use a mix of emacs and hemlock to do my lisp development in openmcl.
> Hemlock is still maturing, and in general the IDE organization is
> still not fully there yet or I'd be using emacs less. I haven't looked
> at Clotho (does it run under openmcl? I should probably look into it).
> If I had spare time to spend it would be on beefing up the IDE for
> openmcl (cleaning up, revising, or integrating the backtrace,
> inspector, etc.) or debugging the Cocoa frontent/PHemlock backend
> under openmcl, and taking lessons learned from there back into the
> main PHemlock project.
Clotho only runs under OpenMCL. I was mucking around with tools for
building applications (that I used to build Alpaca and Hansa2), and an
email conversation sprang up about whether it would be a good idea to
build an open-source IDE for Common Lisp on OSX. So I hacked at Alpaca
until it looked less like a word processor and more like an IDE.
Clotho was originally built using Cocoa, on top of some templates I had
that (again in response to queries) I tidied up and released under the
name of Bosco. However, the OS-version specificity of the current Cocoa
bridge caused me more grief than I expected, so I overhauled Bosco to
build either Cocoa or Carbon apps. I am now overhauling Clotho to be
built on the Carbon side of Bosco, and it's coming along more smoothly
than I expected.
I can see why you would choose to build on Cocoa; it is indeed the
framework that gets all the attention. There are some advantages,
notably that the Cocoa frameworks do more gruntwork for you than the
Carbon frameworks do, and that Objective C has an actual runtime with
some reflection capabilities, so you can talk to objects and find out
On the other hand, Carbon has some things to recommend it, and it is
not true that all new features are supported by Cocoa but not Carbon.
Apple tries to make all Cocoa features supported by Carbon and
vice-versa (they don't succeed; both frameworks are too big for them to
succeed), and they continue to introduce new features in Carbon (e.g.
HIViews). They also write many of their own apps in Carbon (notably,
Carbon UI is perceptibly faster than Cocoa, a fact that is quite
noticeable to me right now, as I'm building UI thingies for Clotho in
I can build Carbon apps on one version of OSX that run just fine on
other versions of OSX.
And in some ways, the very lower-level nature of Carbon, though it
means more gruntwork to get things working well, makes it easier to
integrate into a Lisp application, simply because the API consists of
smaller, simpler pieces that are easier to assemble into Lispy
aggregates. Cocoa by contrast has a relatively strongly-held worldview,
and either your Lisp code ends up looking like parenthesized Objective
C code, or you end up fighting with the Cocoa worldview. Not that I
object to the Cocoa worldivew; I am comfortable with it. But when
wrapping Carbon API calls I feel freer to devise APIs that seem to me
natural in Lisp.
The next release of Clotho will be built on Carbon. What happens after
that depends on some combination of how well that turns out and how
well the Cocoa bridge is working when it's time to build another
More information about the Openmcl-devel