<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">For what it’s worth, the Lua Programming language also has a similar C API to Ruby. So it might be worth writing very simple glue code for the most common dynamic languages to see how the <font face="Menlo" class="">DynamicMemberLookupProtocol</font> and <font face="Menlo" class="">DynamicCallable</font> protocols hold up before the proposals are considered for approval.<div class=""><br class=""></div><div class="">David.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 20 Nov 2017, at 09:16, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Chris,<div class=""><br class=""></div><div class="">I’ve had a quick look into how your proposals will allow interop with other dynamic languages. It seems that the model that you chose, where calling a function is a two-step process (getting a <font face="Menlo" class="">DynamicCallable</font> function from a <font face="Menlo" class="">DynamicMemberLookupProtocol</font> type) fits Python like a glove, where everything (including functions) is a PyVal. But in other languages, like Ruby, this model makes less sense.</div><div class=""><br class=""></div><div class="">For example, here is how one uses the Ruby C API to call a method of an object:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">result = rb_funcallv(obj, rb_intern(“methodName"), arg_count, args);</font></div><div class=""><br class=""></div><div class="">And here is how one gets and sets instance variables:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">x = rb_iv_get(obj, "@x");<br class="">rb_iv_set(obj, "@x", x);</font></div><div class=""><br class=""></div><div class="">Moreover, Ruby allows classes to have instance variables with the same name as methods:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">class Foo</font><div class=""><font face="Menlo" class=""> def initialize()<br class=""> @bar = 5<br class=""> end</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><font face="Menlo" class=""> def bar()</font><div class=""><font face="Menlo" class=""> puts “Hello"</font></div><div class=""><font face="Menlo" class=""> end</font></div><font face="Menlo" class="">end</font></div><div class=""><br class=""></div><div class="">In that case, how would one implement <font face="Menlo" class="">DynamicMemberLookupProtocol</font> for the lookup of <font face="Menlo" class="">bar</font>, and what would the return value be? Its entirely context sensitive.</div><div class=""><br class=""></div><div class="">If we want a model that fits the most languages, shouldn’t we redefine DynamicCallable to specify the function name?</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">protocol DynamicCallable {<br class=""> associatedtype DynamicCallableArgument<br class=""> associatedtype DynamicCallableResult</font><div class=""><font face="Menlo" class=""><br class=""></font></div><font face="Menlo" class=""> func dynamicCall(function: String, arguments: [(String, DynamicCallableArgument)]) throws -> DynamicCallableResult</font><div class=""><font face="Menlo" class="">}</font></div><div class=""><br class=""></div><div class="">This would work in both languages:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">extension PyVal: DynamicMemberLookupProtocol, DynamicCallable {</font></div><div class=""><font face="Menlo" class=""> func dynamicCall(function: String, arguments: [(String, PyVal)]) throws -> PyVal {</font></div><div class=""><font face="Menlo" class=""> let functionVal = self[function]</font></div><div class=""><font face="Menlo" class=""> functionVal.call(arguments)</font></div><div class=""><font face="Menlo" class=""> }</font></div><div class=""><font face="Menlo" class="">}</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class="">extension RbVal: DynamicMemberLookupProtocol, DynamicCallable {</font></div><div class=""><font face="Menlo" class=""> func dynamicCall(function: String, arguments: [(String, PyVal)]) throws -> PyVal {</font></div><div class=""><font face="Menlo" class=""> return rb_funcallv(self, rb_intern(function), arguments.count, arguments);</font></div><div class=""><font face="Menlo" class=""> }</font></div><div class=""><font face="Menlo" class="">}</font></div><div class=""><br class=""></div><div class="">Thoughts?</div><div class="">David.</div><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 20 Nov 2017, at 03:16, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi all,<br class=""><br class="">As I mentioned on a couple other threads, I’ve been working on improving Swift interoperability with Python. I have two pitches out: one to improve Python member lookup and one to improve calls to Python values. While those proposals are important, I think it is also useful to see what can be accomplished with Swift today.<br class=""><br class="">To show you how far we can get, here is a Swift playground (tested with Xcode 9) that has an example interoperability layer, and a tutorial for using it. If you’re interested in the pitches, or in Python, please check it out:<br class=""><br class=""><span id="cid:CE41A451-8E2D-469F-A192-A935CAC70C84@home" class=""><PythonInterop.playground.zip></span><br class=""><br class="">In addition to showing how far the interop can go today (which is really quite far) it shows what the future will look like assuming the member lookup and call issues are resolved. To reiterate what I said on the pitch threads, I am not attached at all to the details of the two pitches themselves, I simply want the problems they address to be solved.<br class=""><br class="">Finally, of course I also welcome questions and feedback on the actual approach, naming, and other suggestions to improve the model! Thanks,<br class=""><br class="">-Chris<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>