Re: Thinking (again) about an Objective-C bridge

The obj-c runtime provides functions for converting a string to 
a selector and for introspecting a method for its parameter 
types.  There will be some variations when a Dylan object maps 
onto, say, an int, not NSNumber, but it appears straight forward 
to handle these cases.

Another consideration is memory management and handling the 
deallocation of objects returned by the objc runtime. Not 
knowing much about how Dylan works, I assume there is a way to 
handle this reliably so that when Dylan objects are garbage 
collected, objc ones in there slots can be dealloc'ed.

Matt

On 6/18/13 at 3:51 PM, [email protected] (Dustin Voss) wrote:

>No, I think it is doable. There are two different macro syntax styles:
>
>objc/send(string, length) // no arguments
>objc/send(string, lengthOfBytesUsingEncoding:, NSUTF8StringEncoding) // arguments
>
>For the first form, let’s say the 2nd argument is called 
>?no-arg-selector-name; the macro would generate a string for 
>the selector via the ?”no-arg-selector” template substitution.
>
>For the second form, the 2nd and subsequent arguments would be 
>parsed pairwise. The first of each pair would be pulled out 
>into one list, each element of which would be turned into a 
>string via ??”selector-parts” or something. The compiler 
>would automatically concatenate those adjacent strings, 
>yielding a valid selector string. The second of each pair would 
>be put in a separate list and appended to the %call-c-function 
>invocation as varargs.
>
>One problem is how to convert a string to a selector. AFAIK, 
>the only way is NSSelectorFromString. Now, we can cache its 
>return value in a global <string-table>, falling back to using 
>that function call when we haven’t already discovered our SEL.
>
>A second problem is how to know which variation of objc_msgSend 
>to call. We need to do some work to find the SEL anyway; 
>let’s just grab the type encoding as well, examine it to 
>figure out which variation we need, and save that metadata 
>about the selector alongside the SEL itself.
>
>But the real problem is that objc_msgSend and its relatives use 
>varargs. We need a primitive that can deal with varargs, and 
>apparently %call-c-function ain’t it.
>
>Is it enough to relax the error-checking on %call-c-function so 
>that it doesn’t balk when the same C function is called with 
>differing numbers of arguments?
>
>
>
>On Jun 13, 2013, at 9:35 PM, Bruce Mitchener <[email protected]> wrote:
>
>>Maybe I'm having a failure of imagination, but I'm having trouble seeing a macro doing something like:
>>
>>objc/send(receiver, someMessage)
>>
>>into:
>>
>>%call-c-function("objc_msgSend")
>>(id :: <raw-machine-word>, sel :: <raw-machine-word>)
>>=> (obj :: <raw-machine-word>)
>>(primitive-unwrap-machine-word(c.raw-class),
>>primitive-unwrap-machine-word(s.raw-selector))
>>end;
>>
>>Much less handling:
>>
>>objc/send(receiver, someMessage: arg, withValue: value)
>>
>>How do you see that working?
>>
>>I wouldn't want it doing the string concatenations at run-time. It'd be nice if we could avoid the
>selector lookups at each invocation of the call as well.
>>
>>- Bruce
>>
>>
>>
>>On Fri, Jun 14, 2013 at 10:25 AM, Bruce Hoult <[email protected]> wrote:
>>Ideally, what you want is:
>>
>>- grab the symbols for the method and additional argument names
>>- convert to strings and concatenate
>>- create a global variable with that name (prefixed) to hold the selector value.
>>- add the var and string to a hash table (or generate code) to look up the selector value at program
>startup
>>
>>I don't think there's anything there that Dylan macros can't do.
>>
>>
>>On Fri, Jun 14, 2013 at 3:07 PM, Bruce Mitchener <[email protected]> wrote:
>>One of the issues to solve in doing an Objective-C bridge for Dylan is how to represent a method
>invocation on the Dylan side.
>>
>>In C, we have %call-c-function, which looks like:
>>
>>%call-c-function (?name:expression, #key ?c-modifiers:expression = "")
>>(?parameters:*) => (?results:*)
>>(?arguments:*)
>>end;
>>
>>In LispWorks, they use this sort of syntax:
>>
>>(invoke window "close")
>>(invoke box "setWidth:height:" 10 20)
>>
>>In ClozureCL, this is the syntax:
>>
>>(send w :set-alpha-value 0.5)
>>(send v :mouse p :in-rect r)
>>
>>In Python:
>>
>>anObject.modifyArg_andAnother_(arg1, arg2)
>>
>>Overall, I like the approach used by ClozureCL as it seems much more natural and more like the
>Objective-C that one would see. They've also got variants of 
>sending to the superclass, sending when a structure is 
>returned, etc.  Having the keywords and the arguments alternate 
>makes it nicely readable (much more so than the LispWorks example).
>>
>>In ClozureCL, a lot of the work is done by macros, but I don't think our macros in Dylan are powerful
>enough to do the same work. So what can we get away with? We 
>don't want a lot of work being done at run-time as we'd like 
>for this to be as efficient as possible.
>>
>>My thinking is that we might need a custom converter, much like %call-c-function has, with the
>corresponding compiler support.  I'd love to be proved wrong 
>though, so what thoughts do any of you have on this?
>>
>>- Bruce
>>
>>
>>-- 
>>This message has been scanned for viruses and dangerous 
>>content by MailScanner, and is believed to be clean. _______________________________________________
>>hackers mailing list
>>[email protected]
>>https://lists.opendylan.org/mailman/listinfo/hackers
>>
>>
>>
>>_______________________________________________
>>hackers mailing list
>>[email protected]
>>https://lists.opendylan.org/mailman/listinfo/hackers
>>
>>
>>_______________________________________________
>>hackers mailing list
>>[email protected]
>>https://lists.opendylan.org/mailman/listinfo/hackers
>
>
>
>-----
>_______________________________________________
>hackers mailing list
>[email protected]
>https://lists.opendylan.org/mailman/listinfo/hackers
>
_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers