On Nov 10, 2017, at 5:51 PM, Slava Pestov via swift-evolution
<swift-evolution@swift.org> wrote:
> Hi Chris,
>
>> On Nov 10, 2017, at 9:37 AM, Chris Lattner via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> Hello all,
>>
>> I have a couple of proposals cooking in a quest to make Swift interoperate
>> with dynamically typed languages like Python better. Instead of baking in
>> hard coded support for one language or the other, I’m preferring to add a
>> few small but general purpose capabilities to Swift. This is the first,
>> which allows a Swift type to become “callable”.
>
> I’m generally in favor of adding new features if they simplify the language
> model or subsume existing special cases, either moving them into the standard
> library or simplifying their implementation.
Great!
> However this proposal looks like a strictly additive feature,
It is. It is strictly sugar, as mentioned in the proposal.
> which introduces yet another kind of callable thing. We already have:
>
> - Statically dispatched functions
> - VTable-dispatched class methods
> - Witness table dispatched protocol methods
> - ObjC methods
> - Dynamic method dispatch on AnyObject
> - Enum case constructors
> - Curried functions and various thunks, etc
>
> I don’t see the new dynamic callable you are proposing replacing or
> generalizing any of the above, it will simply be a whole new code path.
These things are completely different in character. They are not sugar: they
are invasive changes that spread through the rest of the compiler. They are
also (generally) not part of the user exposed semantic model for swift, they
are implementation mechanics. This proposal if far less invasive, and also
quite different than these.
> This all comes at a great cost. If you look at the implementation of calls in
> lib/SILGen/SILGenApply.cpp you will see there is a great deal of complexity
> there to deal with all the different special cases. The type checker also has
> a lot of complexity related to method calls and member accesses.
I do not expect any SIL or IRGen changes associated with this proposal, just
type checker changes. The type checker changes should be straight-forward, but
you can evaluate that when there is a patch.
>
>> Swift is well known for being exceptional at interworking with existing C
>> and Objective-C APIs, but its support for calling APIs written in scripting
>> langauges like Python, Perl, and Ruby is quite lacking. These languages
>> provide an extremely dynamic programming model where almost everything is
>> discovered at runtime.
>
> Most other statically compiled languages don’t attempt to solve this problem
> of interoperating with Python and Ruby either.
Our goal is for Swift to be awesome, not comparable to “other statically typed
languages”.
> I’m not sure this is a feature users expect or one that should be
> prioritized, given all the other work that remains in the implementation that
> will actually improve the day to day experience of developers.
swift-evolution isn’t about priorities. I’m not asking someone else to
implement this, and you don’t tell me how I spend my engineering time :-) :-)
>
>> We propose introducing this protocol to the standard library:
>>
>> protocol DynamicCallable {
>> associatedtype DynamicCallableArgument
>> associatedtype DynamicCallableResult
>>
>> func dynamicCall(arguments: [(String, DynamicCallableArgument)]) throws ->
>> DynamicCallableResult
>> }
> This is not really very general at all, because it assumes all arguments have
> the same type, along with all results.
Correct. This is important and common for interoperating with dynamic
languages.
> Why would arguments and results have different types if they’re type erased
> anyway?
I’m open to requiring these to be the same type if there is a benefit to doing
so. What benefit do you see?
> And why are string keyword names privileged in any way? What about varargs,
> inout parameters and other Swift-specific modifiers on calls?
Because dynamic languages support keywords, and this is all about reflecting
APIs written in those languages into Swift. This API works fine for varargs.
Dynamic languages do not support Swift specific keywords and (generally) do not
support inout.
-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
