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 > <[email protected]> wrote: > >> On Nov 11, 2017, at 7:02 AM, Joe Groff via swift-evolution >> <[email protected] <mailto:[email protected]>> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
