It would be really nice if Cython code could be linked into iOS and Mac apps 
written in Swift or Objective-C.

http://cython.org

--
C. Keith Ray
Senior Software Engineer / Trainer / Agile Coach
* http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf



> On Oct 29, 2017, at 1:34 PM, Chris Lattner via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
>> 
>> On Oct 29, 2017, at 8:23 AM, Chris Lattner via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> 
>>> On Oct 29, 2017, at 4:04 AM, Lukas Stabe <lu...@stabe.de> wrote:
>>> 
>>>> On 28. Oct 2017, at 23:10, Chris Lattner via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>> … which is to say, exactly identical to the Python version except that new 
>>>> variables need to be declared with let/var.  This can be done by blessing 
>>>> Python.Object (which is identical to “PyObject*” at the machine level) 
>>>> with some special dynamic name lookup behavior:  Dot syntax turns into a 
>>>> call to PyObject_GetAttrString, subscripts turn into PyObject_GetItem, 
>>>> calls turn into PyObject_Call, etc. ARC would be implemented with INCREF 
>>>> etc.
>>> 
>>> That sounds like a very interesting prospect. Do you think it would make 
>>> sense to make the language features that facilitate this (dynamic dispatch 
>>> of method calls, property accesses, subscript and ARC) available to Swift 
>>> classes annotated in some way, so that interop like this can be implemented 
>>> as a library without special treatment by the Swift compiler? This could 
>>> also enable more dynamic DSL like features.
>> 
>> I haven’t explored enough of the design space to be sure, but I’d want to 
>> make sure that a library version of this could be done without giving up 
>> ergonomics of the result.  If you were interested in being able to interop 
>> with other languages that are dynamically typed and reference counted, then 
>> something like this could be possible in principle:
> 
> Thinking about the Perl case makes it clear to me that this should not be 
> built into the compiler as a monolithic thing.  Perl supports several 
> different types (SV/AV/HV) which represent different concepts (scalars, 
> arrays, hashes) so baking it all together into one thing would be the wrong 
> way to map it.  In fact, the magic we need is pretty small, and seems 
> generally useful for other things.  Consider a design like this:
> 
> 
> // not magic, things like Int, String and many other conform to this. 
> protocol Pythonable {
>  init?(_ : PythonObject)
>  func toPython() -> PythonObject
> }
> 
> // Not magic.
> struct PythonObject : /*protocols below*/ {
>   var state : UnsafePointer<PyObject>
> 
>   subscript(_ : Pythonable…) -> PythonObject {
>     ...
>   }
> }
> 
> // Magic, must be on the struct definition.  
> // Could alternatively allow custom copy/move/… ctors like C++.
> protocol CustomValueWitnessTable {
>  static func init(..)
>  static func copy(..)
>  static func move(..)
>  static func destroy(..)
> }
> 
> // Magic, allows anyobject-like member lookup on a type when lookup otherwise 
> fails.
> protocol DynamicMemberLookupable {
>   associatedtype MemberLookupResultType
>   func dynamicMemberLookup(_ : String) -> MemberLookupResultType
> }
> 
> // Magic, allows “overloaded/sugared postfix ()”.
> protocol CustomCallable {
>  func call( …)
> }
> 
> The only tricky thing about this is the call part of things.  At least in the 
> case of python, we want something like this:
> 
>   foo.bar(1, 2, a: x, b: y)
> 
> to turn into:
>  foo.dynamicMemberLookup(“bar”).call(1, 2, kwargs: [“a”:x, “b”:y])
> 
> We don’t want this to be a memberlookup of a value that has “bar” as a 
> basename and “a:” and “b:” as parameter labels.
> 
> -Chris
> 
>> 
>> protocol DynamicDispatchable { // Protocol is “magic" known by the compiler.
>> func retain()
>> func release()
>> func memberLookup(_ : String) -> Self
>> func subscript<T>(_ : T) -> Self
>> func call(_ args: [Self]) -> Self
>> } 
>> 
>> module Python {
>> struct Object : DynamicDispatchable {
>>   var state : UnsafePointer<PyObject>
>> 
>>   func retain() {
>>      INCREF(self)
>>  }
>> 
>>    func memberLookup(_ : String) -> Object {
>>       PyObject_GetAttrString(…)
>>    }
>>   etc
>> }
>> 
>> module Perl5 { 
>>  struct Object : DynamicDispatchable {
>>   var state : UnsafePointer<SV>
>> 
>>   func retain() {
>>      SvREFCNT_inc(self)
>>  }
>> ….
>> 
>> 
>> 
>> Are there other uses for such a thing?
>> 
>> -Chris
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to