[swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

[Chris Lattner]

On Nov 10, 2017, at 5:51 PM, Slava Pestov via swift-evolution <swift-evolution at swift.org> wrote:
> Hi Chris,
> 
>> On Nov 10, 2017, at 9:37 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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

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