> On Oct 29, 2017, at 3:23 PM, C. Keith Ray <keith...@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@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Oct 29, 2017, at 8:23 AM, Chris Lattner via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> >>>> On Oct 29, 2017, at 4:04 AM, Lukas Stabe <lu...@stabe.de >>>> <mailto:lu...@stabe.de>> wrote: >>>> >>>>> On 28. Oct 2017, at 23:10, Chris Lattner via swift-evolution >>>>> <swift-evolution@swift.org <mailto: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 <mailto: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
