[swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics

[Chris Lattner]

> On Oct 29, 2017, at 3:23 PM, C. Keith Ray <keithray at mac.com> wrote:
> 
> 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 <http://cython.org/>
Isn’t that possible today, at least on the Mac?

-Chris


> 
> --
> C. Keith Ray
> Senior Software Engineer / Trainer / Agile Coach
> * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf <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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> On Oct 29, 2017, at 8:23 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>>> On Oct 29, 2017, at 4:04 AM, Lukas Stabe <lukas at stabe.de <mailto:lukas at stabe.de>> wrote:
>>>> 
>>>>> On 28. Oct 2017, at 23:10, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171029/486c3e35/attachment.html>