[Openmcl-devel] Using Cocoa with MCL

[Gary Byers]

On Thu, 8 May 2003, Randall Beer wrote:

> Since I'm one of the people who expressed an interest in this a few
> months ago, I felt compelled (shamed?) into replying.

The Cocoa demo's pretty much stood still (except for Alpaca and
anything similar that anyone else might be doing) for a long time;
there's plenty of shame to go around.

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

Someone (perhaps Randall) pointed out that it's possible to peer
into the ObjC runtime and find all classes; an ObjC class keeps
track of its methods and their signatures, so it might be possible
to automate the generation of procedural CL wrappers around
everything.

Suppose at this procedural level it was possible to say something
like:

(cocoa:init (cocoa:class-alloc *nswindow-class*)
                  :content-rect r	  ; details, details
                  :defer nil
                  :style-mask (logior ...))

e.g., there's a predictable one-to-one correspondence between an
ObjC method and a functional lisp interface to it (and hopefully
that functional lisp interface to it looks better than my example.
Some keyword arguments are elided from the example above, more
to save myself some typing than because I can think of plausible
defaults.)

Presumably, the implementation of NSWINDOW-INSTANCE-INIT is
very little more than some FFI gunk; the immediately obvious
advantage of this scheme is that we don't have to read or write
that FFI gunk ourselves.

I don't know that I'd want to try to write a large application
at this level, but I don't know that I'd want to try to write
a high-level Cocoa library (that'd ideally make it easier for
people to write large applications) strictly at the FFI+reader
macro level either.

[It -might- be possible/practical to write little one-shot
programs at the "functional lisp interface" level; however it's
done, it should ideally be easy to write little throwaway/demo
programs as well as large sophisticated ones.]

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

I'd be willing to bet that the first N attempts (for hopefully small
values of N) at a Cocoa-CLOS hybrid would be things that we should
(or should in hindsight) plan on throwing away.

That suggests that we have a need for something that'd make it easy to
experiment with and prototype higher-level solutions.  I don't think
that the status quo (FFI + reader macros) fills that need too well
and that a bit more infrastructure is required.  The next level or
two up - somewhere around the "functional lisp interface" - might
still be very low-level and not as lisp-like as most people'd want,
but it'd enable more people to do things than the current level does
and would make it easier for the next-higher level to be built.

I agree completely that there are lots of design issues as well as
technical ones.  The best solution might turn out to be several
solutions:  something that tracks Cocoa as closely as possible (and
exploits lisp's advantages while doing so) is attractive,   McCLIM
is attractive for different reasons.  If there were several (or at least
a few) solutions for doing high-level GUI programming in OpenMCL, I
don't think that that'd be a bad thing.

I do think that designing an application framework is a hard problem.
A lot of work went into the design and implementation of MCL's class
library; one can either note how it shows signs of age and inflexibility
or note that it's taken as long as it has for those signs to appear to
the degree that they have.

Whatever the high-level solution(s) turn out to be, it doesn't seem
likely that the middle layer (the functional/procedural interface)
will design itself.  If the goal is to derive large parts of that
middle-layer automatically, we have part of what we need (the ability
to ask ObjC for all foreign method names and signatures); the part
that's missing is a policy that'd guide that translation process.

As an example: suppose that there's a Cocoa method that returns an
:<NSR>ange structure.  The way that structure return is implemented
in most C compilers is that the caller allocates a structure and
passes a pointer to it as an invisble parameter to the callee; the
callee just fills in its fields.  This is exposed in the FFI-based
Cocoa code; would we want it to be exposed at a middle level ?  I
can think of arguments pro and con, which suggests that there may
be more than one level in the middle ...




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