> On Nov 11, 2017, at 7:02 AM, Joe Groff via swift-evolution > <swift-evolution@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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
