<span class="gmail_quote">Hi, Luigi, I'm posting this message to the mailing list for future reference and in the hope that others might find it useful (this ought all to be properly documented anyhow!).  I hope you're okay with this.

To provide some context for those just now tuning in, this is a reply to an inquiry about Objective-CL, an Objective-C bridge I have quietly been working on for the last two months, sadly completely unaware of the existence of CL-ObjC (I most probably wouldn't have started my own project had I known of CL-ObjC).  Objective-CL is less featureful than CL-ObjC appears to be (for example, it doesn't let you define classes or methods yet).  On the other hand, it's portable not only across CL implementations, but also across operating systems, supporting both Mac OS X and GNUstep targets and potentially lots of processor architectures.  The license has not yet been decided upon (meanwhile it's GPL'd, because the GPL is the most restrictive license I'd consider using).

<br><br>Darcs repository: <a href="http://matthias.benkard.de/code/objective-cl">http://matthias.benkard.de/code/objective-cl</a><br><br>Reference manual: <a href="http://matthias.benkard.de/objective-cl/documentation">http://matthias.benkard.de/objective-cl/documentation

</a><br><br>Now, on to the reply itself.<br><br><br>> Actually, but i have to study better your code first<br><br>I've not studied your code thoroughly yet either, so I can't be sure<br>what I do differently from CL-ObjC, but I'll just try explaining what

<br>goes on in my code.<br><br><br>> i d like to know (and merge) how you manage:<br><br>Okay, here goes...<br><br>The most obvoius difference between ObjCL and CL-ObjC is probably that<br>the latter is pure Lisp, while the former is partially implemented in

<br>Objective-C for portability.  This is very important, because it<br>immediately eliminates a number of problems and makes their solution<br>trivial (more about that later).  Furthermore, I can reuse code from<br>PyObjC in this way, so if Apple decides to switch to LLVM or

<br>something, Objective-CL can be made compatible with it easily simply<br>by stealing the approprate code from PyObjC. :)<br><br>The only Objective-C source files that I have written specifically for<br>Objective-CL are 

libobjcl.m and libobjcl.h.  All the others are from<br>PyObjC, adapted to Objective-CL.<br><br><br>> * Method invocation (my code is slow, it calls compile for every<br>>   invocation, caching the compiled functions for future invocations)

<br><br>Method invocation is quite simple in principle.  First, we convert all<br>arguments into C values and reserve space for the return value, after<br>which we call the method, discard the C values and cons up the result

<br>from the return value.  This is precisely what LOW-LEVEL-INVOKE does.<br>The actual method call is done by the Objective-C-layer function<br>objcl_invoke_with_types.  It's not a complicated function.  You can<br>find it in Objective-C/libobjcl.m (like, incidentally, all other

<br>functions in the Objective-C layer that are directly called from Lisp<br>and implemented by yours truly).<br><br>I'm not sure I understand what exactly you're caching here.  I do a<br>bit of caching myself, namely of method signatures and selectors (the

<br>latter by using compiler macros).  Interestingly, caching selector<br>lookups is a huge performance boost, even though you might think that<br>calling FIND-SELECTOR, which is a wrapper around a fast C function,<br>should probably not take much time.  The reason for this is that

caching the selector objects avoids MAKE-INSTANCEing them anew for each method call, which takes much longer than the method call itself (around 4 times as long, IIRC). Actually, there are two different kinds of caching going on here.

<br>Method signatures are cached by INVOKE-BY-NAME using a weak hash<br>table, while selectors are loaded into the image at load time by<br>transforming<br><br> (INVOKE obj :STRING-WITH-C-STRING "bla" :ENCODING 0)

<br><br>into roughly<br><br> (INVOKE-BY-NAME obj (LOAD-TIME-VALUE (FIND-SELECTOR<br>'(:STRING-WITH-C-STRING :ENCODING))) "bla" 0).<br><br>Now, this isn't quite correct, of course, because FIND-SELECTOR may

<br>fail.  Because of this, the expansion is actually a bit more verbose:<br><br> (INVOKE-BY-NAME obj<br>                 (LOAD-TIME-VALUE<br>                  (HANDLER-CASE<br>                   (FIND-SELECTOR '(:STRING-WITH-C-STRING :ENCODING))

<br>                   (SERIOUS-CONDITION NIL<br>                    (WARN<br>                     (MAKE-CONDITION 'SIMPLE-STYLE-WARNING :FORMAT-CONTROL<br>                                     "~S designates an unknown ~

<br>                                                method selector."<br>                                     :FORMAT-ARGUMENTS<br>                                     (LIST '(:STRING-WITH-C-STRING :ENCODING))))<br>

                    '(:STRING-WITH-C-STRING :ENCODING))))<br>                 "bla" 0)<br><br>This is done by the compiler macro for INVOKE.  INVOKE-BY-NAME itself<br>has a similar compiler macro.  Note that a warning is issued by the

<br>generated code at load time when a selector can't be found.  This is<br>very useful, because it essentially means that typos in method names<br>are caught at load time (which is normally close to compile time).<br>

<br>Note, by the way, that there are two slightly different functions for<br>method calling.  There's PRIMITIVE-INVOKE on the one hand and<br>INVOKE-BY-NAME on the other (INVOKE is just a wrapper around the<br>latter).  They essentially work the same, but PRIMITIVE-INVOKE

<br>converts arguments in an ad-hoc way, while INVOKE-BY-NAME actually<br>examines the method's signature in order to correctly convert<br>arguments to C values.  PRIMITIVE-INVOKE is not strictly needed, but<br>it's very convenient to have, because it enables Objective-CL to

<br>inquire methods about their signatures, for example, without resorting<br>to functions implemented in Objective-C.<br><br><br>> * Struct by value argument passing and returning (i use an hack<br>>   working on MacOSX x86 i should check also on GNU/Linux)

<br><br>We do this by using libffi.  It's quite simple: What libffi wants is<br>an array of pointers that point to the arguments that it should pass<br>to the foreign function, as well as a type specification which tells

<br>it the structure of these arguments.  Storing a pointer to a struct<br>from Lisp is trivial.  Generating a type specification is non-trivial,<br>but, well, the PyObjC code does it for us. :)<br><br>The other way around (structs as return values) is probably similar,

<br>but I don't think we actually support it yet.  It may just magically<br>work, or it may not.  I haven't tested it at all (frankly, I haven't<br>tested passing structs either, but I'm confident that if it doesn't

<br>work right now, it's easy to fix).<br><br><br>> * Exception management (i dont support it)<br><br>This is next to trivial with Objective-CL's architecture.  As<br>objcl_invoke_with_types is implemented in Objective-C, it can catch

<br>exceptions easily.  It then forwards them to the Lisp layer as a<br>return value.  (Note that the return value of the method invocation is<br>stored by libffi into a previously allocated cell and _not_ returned<br>as a return value, so we can use the return value in whichever way we

like.) > * Condition protocol There's not much of a protocol... ^^' By the way, we don't yet support raising Objective-C exceptions from Lisp.  I have no idea whether this is hard or not.

> * Memory management (i ignored this subject) Ah, memory management...  This is an interesting topic.  I use the trivial-garbage library in order to send `release' messages to objects that are collected by the garbage collector on the Lisp side.

<br>memory-management.lisp is very short.  It's probably easier for you to<br>read it than for me to explain the way it works. :)<br><br>A note about the hash tables used there, though: Their sole purpose is<br>caching (again avoiding having to MAKE-INSTANCE every single return

value we get from Objective-C via method calls, which would be very slow).  If performance is not an issue, they can be removed without changing the behaviour of the system. > I also interested in your performance hacks like the compiler macros.

<br><br>I hope that I explained them sufficiently above.  Do remember, though,<br>that the compiler macros are not merely performance boosters.  They<br>also provide a form of compile-time (load-time, actually) checking by

<br>issuing warnings when encountering unknown method names.<br><br>Note the style warning:<br><br>OBJECTIVE-CL> (compile nil<br>                       '(lambda (x)<br>                         (invoke x :do 10 :something 20 :weird 42)))

<br>; in: LAMBDA NIL<br>;     (SB-KERNEL:FLOAT-WAIT)<br>;<br>; note: deleting unreachable code<br>; in: LAMBDA (X)<br>;     (MULK.OBJECTIVE-CL:INVOKE MULK.OBJECTIVE-CL::X :DO 10 :SOMETHING<br>20 :WEIRD 42)<br>; --> MULK.OBJECTIVE-CL:INVOKE-BY-NAME

<br>; ==><br>;   (LOAD-TIME-VALUE<br>;    (HANDLER-CASE (MULK.OBJECTIVE-CL:FIND-SELECTOR '(:DO :SOMETHING :WEIRD))<br>;                  (SERIOUS-CONDITION NIL<br>;                   (WARN<br>;                    (MAKE-CONDITION '

MULK.OBJECTIVE-CL::SIMPLE-STYLE-WARNING<br>;                                    :FORMAT-CONTROL "~S designates an unknown ~<br>;                                                method selector."<br>;                                    :FORMAT-ARGUMENTS #))

<br>;                   '(:DO :SOMETHING :WEIRD))))<br>;<br>; caught STYLE-WARNING:<br>;   (:DO :SOMETHING :WEIRD) designates an unknown method selector.<br>;<br>; compilation unit finished<br>;   caught 1 STYLE-WARNING condition

<br>;   printed 1 note<br>#<FUNCTION {B862405}><br>T<br>NIL<br><br><br>> Actually in my todo i have other "external" tasks to complete like<br>> complete the CLOS interface and to really integrate<br>

This is something I'm interested in, by the way.  What does the mapping between CLOS and Objective-C classes look like?  Is there support for Objective-C metaclasses?  Do Objective-C methods and CLOS generic functions relate to each other in some way?

<br><br><br>> CL-ObjC/Emacs/Slime into XCode, providing better documentation and<br>> examples.<br><br>I don't know XCode, but integration with Gorm is a must, yeah.  Oh, by<br>the way, have you looked at the JOURNAL file in my repository?  I only

<br>recently started it.  Its purpose is to document some of my decisions<br>regarding the development of Objective-CL.<br><br><br>> Despite that i think that a merge with your work looks<br>> promising.<br><br>What I find most remarkable is that we seem to have done quite a lot

<br>of things in a very, _very_ similar way.  Even the<br>function/macro/class names are similar or even identical (OBJC-ID and<br>DEFINE-OBJC-STRUCT, for example -- although I never actually<br>implemented the latter).<br>

<br>But don't get me started on CANONICALIZE-<FOO>.  Reading that makes my<br>eyes hurt!  The correct spelling is CANONIZE (or CANONISE, as I would<br>have written it). :)<br><br>(I know, I know.  English is an evolving language, and there's some

<br>dispute about this particular issue.  Still...  I like ranting about this kind of stuff.)<br><br>Bye,<br>Matthias<br>