[Openmcl-devel] Using Cocoa with MCL

[Gary Byers]

On Mon, 5 May 2003, it was written:

> Hi everybody,
>
> I am playing around with OpenMCL under OSX, haven't done any serious
> programming for years, so at this stage this is more educational then
> anything else. However, educational or not, I am spoiled by such things
> as the travel advisor example in "Learning Cocoa" or the Watson example
> application that comes with AppleScript Studio. If I have to confine
> myself to the comparatively "more pitiful" examples in Lisp
> tutorials/books, I know already that I will get bored and lose interest
> prematurely.
>
> What I would like is an ability to play with the GUI. So, I checked out
> the Coca examples that come with OpenMCL and played with the rudimentary
> IDE. I realise that this falls short of what bread-and-butter
> programmers will need to do actual work, but to me this is a nice
> starting point and I probably won't even fight with Emacs any further.

I would like (for lots of reasons) to make it into something that people
could use to do actual work, and to improve the interoperability between
OpenMCL and Cocoa so that people could more easily develop real applications
with rich GUIs.

>
> Looking at the sources, it seems to me that this stuff is actually
> written in Objective-C with a bit of Lisp wrapped around it. This

It's written in "Lisp that looks like Objective-C, with a bit of Lisp
that looks like lisp wrapped around it."

That distinction means that you can interactively define and redefine
Objective-C methods, but it's certainly true that you have to understand
more than you'd ideally have to about Obj-C and its runtime in order to
understand how the examples work.

> probably means that one has to know/learn both Objective-C and Lisp to
> do anything with it. My skills are not good enough in either language,
> but I would nevertheless like to explore possibilities to play with it.
> Are there any folks out there who are working on either the Cocoa
> interfaces or the IDE or both ?

I know that one person has making an editor (suitable for writing prose)
that uses OpenMCL's Cocoa demo as a starting point: see

<http://alpaca.sourceforge.net>

As far as I know, this is still written in the same "pidgin
Objective-C" as the examples are; the author (Mikel Evins) does
understand a lot about Objective C and its runtime, and Alpaca shows
that it's possible (for some people at least) to extend the code
in the examples in interesting and useful ways.  (That probably
says more about the extensible natures of both Lisp and ObjC - and
about Mikel's persistence - than it does about the usability of
the Lisp<->ObjC code in its present state.)

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.

>
> If so, I would like to know what you are doing. I see in the archives
> that TFB asked about documentation on the Cocoa interfaces. It seems to
> me that if this was better documented, there would probably be more
> folks using and improving it. I am sitting in that boat. I can't really
> figure out how to use this by looking at the sources because my skills
> are limited, yet I cannot read any documentation to learn how to use it.
> Catch 22 ;-)

There are a few other Catch-22's involved: if it were further along
than it is (in a variety of ways), there'd be more people actively
using it; if more people were actively using it, more people would
be thinking about and working on ways to improve it.

There are some low-level issues that are easiest to deal with if
lisp threads are native threads (the Cocoa libraries and ObjC runtime
certainly have no understanding of OpenMCL 0.13's cooperative threads,
and this occasionally matters.)  That's another Catch-22: 0.14 may
still have bugs and rough edges that discourage people from using it
regularly, but it needs people using it (fairly seriously) in order
to expose those bugs and rough edges.

I think that a very desirable next step would be to make Cocoa
programming in OpenMCL a less tedious and error-prone process.  At
the level things have been at for the last year of so, misspelling
or miscapitalizing a method name can lead to a fatal runtime error.
It's hard to integrate the ObjC condition system (such as it is) with
Lisp's, but there are certainly ways that the effects of this type
of mistake can be reduced.

>
> I would love to add things to that rudimentary IDE, ie. a context
> sensitive HyperSpec lookup, drag and drop support, syntax coloring etc
> etc. However, I don't have the skills to do it. What I am good at is
> writing and explaining in layman's terms how things work, provided I
> understand how they work. Therefore, I was wondering, if there are any
> folks working (or interested to work) on those Cocoa interfaces and/or
> that IDE who are willing to put up with stupid questions from my side in
> return for my contributing some documentation.
>

I appreciate the offer and I'd be glad to try to answer any specific
questions that you or anyone else have.

There's -some- documentation on OpenMCL's ffi (on the web site and in
the doc/HTML/ directory in the distribution); if that's at all
understandable, it'd probably be helpful to anyone trying to understand
what's going on in "ccl:examples;apple-objc.lisp".

I've pretty much convinced myself that a better lisp-aware Cocoa editor
would not use the builtin Cocoa text classes as a starting point: it'd
be nice to use Cocoa for event handling and it (or ATSUI or Core Graphics)
for redisplay, but to maintain editor buffers as lisp data structures
(and operations on those buffers as lisp functions/methods.)  Portable
Hemlock <http://www.stud.uni-karlsruhe.de/~unk6/hemlock/> is currently
tied (perhaps a bit too much) to X-Windows/CLX, but in theory it should
be possible to replace the CLX layer with something Cocoa-based (and the
author - a McCLIM developer - certainly wants to reduce/remove the CLX
dependencies.)


> rgds
> bk
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel
>
>

_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel