[Openmcl-devel] Adobe's Lua interface

[Gary Byers]

On Sun, 17 Jun 2007, Toomas Altosaar wrote:

> There was an interesting link on Apple's Carbon list:
>
> At 18:36 -0700 16.06.2007, carbon-dev-request at lists.apple.com wrote:
>> > I would suggest reading this Adobe presentation on the architecture
>>>  of Lightroom, their corporate imperative for economical cross-
>>>  platform development, and how they developed a Mac UI front end
>>>  without using Carbon or Objective-C:
>>>
>> > http://www.lua.org/wshop05/Hamburg.pdf
>
> One of their findings (page 10):
>
> "Primary Lesson: Languages with good introspection make it easy to
> export APIs to Lua"
>
> Is OpenMCL's approach similar to Adobe's? Perhaps even more aggressive?

I haven't read the paper yet, so I don't really know where OpenMCL's
approach stands on The Scale Of Cocoa Interface Aggression ("meek" ?
"belligerent" ?)

I think that a desirable goal would be to expose as much of Cocoa as
possible and hide as much of Objective-C as possible.  (I think that
Cocoa's very, very good, and that the best thing that you can say
about ObjC is that it's a generally very reasonable C dialect, as in
"he's a nice guy, for an axe murderer ...")

It's hard to think of parts of Cocoa that aren't exposed.  (I don't
think that there's an easy way to define a Cocoa method that takes a
variable number of arguments in lisp; that's mostly a limitation of
OpenMCL's FFI; the other things that I can think of at the moment tend
to fall into similar categories.)

The other side of it - hiding ObjC cruft - is hopefully getting
better, but it's not all there yet.  I've been doing a lot of Cocoa
stuff in OpenMCL lately, and I think that I'd characterize it as a
weird mixture of very high level, consistent, well-designed and
well-implemented stuff with occasional low-level crap thrown in
(e.g., arguments passed by/results returned by references, other
FFI arcana.)  If you try to pass a rectangle whose height and/or
width are negative to a Cocoa primitive, there's a very good chance
that you'll see an error message and a relatively clean recovery;
if you do something like:

;;; The last argument here should be an object, not a DOUBLE-FLOAT
(#/stringWithFormat ns:ns-string #@"hello, %@%% of the world" 75.0d0)

you'll probably crash pretty hard.

I'ts probably not too hard to come up with ad hoc solutions to
things like this (e.g., wrap something that does sanity checking
around #/stringWithFormat: and call that wrapper instead of
calling #/stringWithFormat: directly.)  It's hard to know how
much of this can be automated; practically everything that happens
to make Cocoa classes and methods accessible from lisp happens
automatically and without special-casing much of anything, and it's
not clear how an automated process could look at #/stringWithFormat:,
see potential danger, and create a wrapper that reduces that danger.

It'd be nice if it was possible to completely forget about ObjC
memory management issues.  (It's certainly possible - I've done
so many times - but there are still consequences involved.)  If
and when the ObjC 2.0 GC gets integrated with OpenMCL's GC, it'll
be possible to forget about those issues and not suffer the
consequences.

The fact that both Lisp and the ObjC runtime are dynamic, extensible
systems that offer good introspection facilities is certainly a
good thing.  With a few exceptions (it's hard to add/remove slots
from ObjC classes at runtime), it's possible to develop things in
an incremental, lisp-y way.   Among other things, those facilities
allow for a fairly high degree of integration between the ObjC object
system and CLOS, which in turn offers a lot of benefits (Cocoa objects
print usefully, it's possible to define regular CLOS methods on ObjC
classes ...)  The Cocoa side of this stuff works well: support for
introspection and dynamism clearly isn't an afterthought, but is
an integral part of how things work and have worked for a long time.