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

[John Holdsworth]

One last try at promoting code generators as an alternative means of importing….
It keeps the complexity out of the compiler and you are able to write the “importer” in
the language being imported allowing it to leverage it’s meta data introspection directly.

I’ve prepared a playground which shows how a generated class + limited supporting code
provides an effective way of bridging to Python. As the generated code is just Swift you
have the advantages of the Xcode editor such as code completion available.

https://github.com/johnno1962/SwiftPython/tree/master/SwiftPython.playground <https://github.com/johnno1962/SwiftPython/tree/master/SwiftPython.playground>
https://github.com/johnno1962/SwiftPython/blob/master/SwiftPython.playground/Sources/Complex.swift <https://github.com/johnno1962/SwiftPython/blob/master/SwiftPython.playground/Sources/Complex.swift>

The playground is standalone and the generated class is included as an auxiliary file.
The bridging code would only require updating when the surface of the api changes.
I’ve not written the actual generator script but it should be straightforward for Python.

John.

//: Playground - noun: a place where people can play

var str = "Hello, python integration"

// class Complex is implemented in python

let c = Complex(11.0, 12.0)
print(c.toString(extra: "123"))

c.r
c.add(c: Complex(1.0, 2.0))
c.r

print(c.toString(extra: [1,2,3]))
print(c.toString(extra: [1.0,2.0,3.0]))
print(c.toString(extra: ["a": 1.0, "b": 2.0, "c": [1,2,3]]))

c.toArray()
c.toDictionary()

(11.000000 12.000000 123)
(12.000000 14.000000 [1L, 2L, 3L])
(12.000000 14.000000 [1.0, 2.0, 3.0])
(12.000000 14.000000 {'a': 1.0, 'c': [1L, 2L, 3L], 'b': 2.0})

> On 12 Nov 2017, at 11:45, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Nov 11, 2017, at 7:02 AM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Opening up the compiler architecture to make custom importers easier to write is a great solution to a ton of problems, including yours I think, without adding complexity to the core language. Experience in .NET land seems to show it's a great technique for integrating dynamic systems with static type systems, without poking unnecessary holes in the static language's type system
> 
> 
> I'm keenly interested in custom importers, if only because I would love to treat storyboards and asset catalogs as "languages" and automatically generate typesafe enums for their various stringly-typed identifiers. (Note to anyone in the peanut gallery getting excited: I don't work at Apple and can't make this a part of the toolchain; I just hope they'd do it if they could.)
> 
> But at the same time, I have a hard time seeing that as a great solution for dynamic languages. I've barely used Python, but I work in Ruby on Rails a lot, and Rubyists rely pretty heavily on dynamic features. For instance, the ActiveRecord ORM creates all its accessors on demand through Ruby's `method_missing` feature. Static analysis would be useless for this, and I can't imagine that profile-based analysis would be very reliable. Even the F# Type Providers documentation warns that "You should avoid writing a type provider where a schema isn't available."
> 
> A dynamic dispatch feature, on the other hand, could reliably reproduce Ruby's behavior because every method call would simply be dispatched through Ruby's method-calling machinery, just as a method call in Ruby would be. It's a round hole for the round peg of a dynamic language's dispatch behavior to fit into. Other languages, like Objective-C and C++, could use the square hole of a custom importer.
> 
> Or maybe the right custom importer design could have it both ways, allowing dynamic languages to accept and write a dispatch for unknown methods, while permitting static languages to match against the more specific data they have available. I don't know. All I'm saying is, static languages and dynamic languages are different, and we need the features necessary to support both without making either of them worse. It's quite possible that the best design for static language bridges will look very, very different from the best design for dynamic languages.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> 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/20171112/fdd6d96c/attachment.html>