[Openmcl-devel] Using Cocoa with MCL

[Yannick Versley]

[lots of pertinent and interesting explanations deleted]

> > If we wrap Lisp implementations of ObjC methods with a wrapper that
> > handles Lisp exceptions and rethrows them as ObjC exceptions (in some sane
> > way), we wouldn't have to think about unwinding ObjC handlers, but we
> > would still have the same problems as the Java/ObjC wrapper currently has
> > (means: Lisp exceptions thrown through ObjC code get horribly munged).
> ObjC can't really get its evil, GC-unaware hands on a lisp condition
> object, but it might be able to pass some sort of identifier ("handle")
> around.
What happens with the Java interface (and what I thought about) was that
only a description of the exception was handed down into the ObjC world.
You're right, we can do better than that if we store the exception object
somewhere and put some handle in the userInfo NSDictionary of the
NSException.

> > Possibly, all this would be easier if we had some kind of native interface
> > like JNI in Java that allows C code to interact with Lisp data and code in
> > a clean and easy way.
> If there were an LNI for OpenMCL, it'd mostly consist of C functions
> that tell you that you can't do what you're trying to do.
> OpenMCL's runtime system (with the exception of the GC itself and
> some exception-handling code) isn't written in C and isn't too
> easily accessible from C.
Java potentially has the same problem (a GC that moves things around), and
JNI is designed to cope with that. Nobody says C code has to lay its hands
directly on lisp objects, e.g. you cannot access Java Strings directly,
but you can provide a buffer and ask to get a copy of the string. A
straightforward approach would be to have one vector of local references
(which get freed when the C code returns) and a hash of global references
(which must be freed explicitly) and give the C code only a handle which
is an index into one of these. It's not very performant, but it's somewhat
robust, does not have to do any black magic and would be independent of
the Lisp implementation (so that C code that uses this interface could be
easily used with any Lisp that implements this LNI).

The other point is why anyone would want such a thing. Of course, Lisp
lovers like to do everything in Lisp, and, because of the black magic
present in any modern Lisp implementation, and the speed of compiled Lisp
code, mixing Lisp and C is not as easy or as useful as it is with
Python/Perl/Java and C.

Regards,
Yannick

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