[Openmcl-devel] What is the state of the phemlock included with OpenMCL?

mikel evins mikel at evins.net
Sun Aug 1 23:24:27 UTC 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, 
> etc.
>
> 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 
useful things.

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, 
the Finder).

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 
Carbon windows.

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 
release.

--me




More information about the Openmcl-devel mailing list