[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Dave DeLong]

This email reminded me of something…

One of the beautiful things about the announcement of Swift in 2014 was that no one saw it coming, even though a whole bunch of signs were in place. One of those signs was Objective-C Modules, which *essentially* describe an API in an abstract syntax, so that it can be used from another language. (It was billed as <wavy hands> making compilation faster </wavy hands>, but IIRC this was one of its trojan purposes).

Can that same tactic be used here? Can we somehow generate modules for python code, and then import those modules as the basis for cross-library invocations? 

Dave


> On Dec 1, 2017, at 1:49 PM, Marc Schlichte via swift-evolution <swift-evolution at swift.org> wrote:
> 
> A somewhat extreme alternative could be the use of IDLs and "libs as services“:
> 
> A Python lib could aditionally expose its APIs (or a relevant subset of it) via an IDL. Generators would help with the necessary stub and skeleton code on both Python and Swift sides.
> 
> My impression is that only big libs like TensorFlow are relevant to be bridged anyhow so that the effort to create an IDLized API for that community is acceptable.
> 
> IDLs are an old idea but they seem to get reinvented every now and then. Google has a new one called FIDL for its Fuchsia project: (https://fuchsia.googlesource.com/fidl/ <https://fuchsia.googlesource.com/fidl/>)
> 
> Cheers
> Marc
> 
> 
> 
> 
>> Am 01.12.2017 um 17:07 schrieb Jon Gilbert via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>> 
>> On Dec 1, 2017, at 02:44, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> So the use case here is, how do we make Swift a viable candidate for doing those things which today drive users to Python? The answer here is _not_: build a better Python. Nor does it require, out of the gate, even being as good as Python. The solution is to provide a _reasonably_ ergonomic to _interoperate with libraries available in Python_, with the benefit that those parts that you can write in native Swift will make the overall result safer and faster, etc.
>> 
>> I think we would be better served by a transpiler that translates Python (etc.) into Swift at compile time. 
>> 
>> Look what Google did with j2objc (https://github.com/google/j2objc <https://github.com/google/j2objc>). It translates Java right into Objective C. You can even put your Java code right in XCode and it auto-translates at build time. 
>> 
>> Clearly, this is no small feat, and j2objc is a technical marvel that took world-class engineers years to perfect. 
>> 
>> My point is, “Dynamic Member Lookup” is not the only solution, and it’s not the ideal solution if indeed it compromises the static guarantees of Swift.
>> 
>> Therefore, we should consider what other approaches might entail. The main players in Swift have lots of money and technical resources they could pour into a set of revolutionary transpilers. 
>> 
>> Surely we don’t want to allow Goole to be the only company to provide a library that translates other codebases directly to a primarily Apple language, do we?
>> 
>> That being said, I am still interested to hear Chris’s response to these concerns, and if they were already addressed on a previous message and I missed that, then please forgive me.
>> 
>> - Jon
>> _______________________________________________
>> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171201/0f06c04b/attachment.html>