<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div><br>On Nov 11, 2017, at 1:57 PM, Chris Lattner <<a href="mailto:clattner@nondot.org">clattner@nondot.org</a>> wrote:<br><br></div><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 11, 2017, at 10:17 AM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><div dir="auto" class=""><div class="">so I don't think there's a time constraint forcing us to consider the "narrow" vs "huge" dimension. What's the best thing for the language and tools in the long term? This is a feature that influences the semantics of potentially any call site in all Swift code, which we'd have to live with forever if we accepted it now. 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</div></div></div></blockquote><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></div><div class="">As I mentioned, I’m not familiar with F# type providers. As I told you upthread, I will read about them and respond with an informed opinion when I have time.</div></div></div></blockquote><br class=""></div><div>I have done some quick reading about type providers, but I am certainly not an expert. I have a couple of questions that I’d appreciate your insight on:</div><div><br class=""></div><div>Type providers seem like a (complicated!) compile-time form of meta programming or compiler plugin. How does this help interoperability with dynamic languages, where the preponderance of values have types that are not knowable at compile time?</div><div><br class=""></div><div>To pick a specific example you are familiar with, this seems like it could help in theory (though I suspect it would be be entirely impractical in practice) to provide types for Objective-C methods that are coming from an SDK where you have declarations. </div><div><br class=""></div><div>In contrast, it does *not* seem like it would help with the problem of resolving members of “id” typed values in Objective-C, which is the crux of the dynamic language problem. If my understanding is correct, type providers seem completely unhelpful for python interoperability, because you don’t know the types of python values: anything loaded from a Python property or returned by a Python function is the equivalent of “id”.</div><div><br class=""></div><div>It’s entirely possible I’m missing something big. If so, I’d appreciate a pointer to something to read that explains how this works. Thanks!</div></blockquote><br><div>A type provider should let you provide custom logic for something the compiler sees as a module, which can answer name lookup queries by producing decls based on externally-available information. While Python is dynamic, Python culture doesn't go as wild with dynamic shenanigans as other languages do; there are established idioms for communicating some level of type information in doc comments (or more recently with first class syntax in Python 3), and people like code completion to work with their Python text editors, so there's incentive to use them. A type provider in Swift could address not only the syntax gap but the tooling gap from directly writing Python, since it could answer name lookup requests into an imported Python type by static analysis, and it could bring that declaration into Swift with doc comments and other metadata intact. This would let Python decls get wired up to Swift's code completion, quick help, and other IDE tooling.</div><div><br></div><div>Since statically-available type info still isn't going to be perfect in Python, and we don't want to be boxed in to type-annotated APIs, a type provider could be lax with its name lookup behavior and allow any known Python method to be found on any Python type, much like AnyObject's behavior for ObjC methods (and, like AnyObject, maybe tag them with IUO types so that type safety aficionados can test for their presence, and prioritizing the "good" type-matching methods in code completion results). I don't think that's a totally silly idea; much like AnyObject lookup is strictly an ObjC interop feature, I think there'd be benefit to keeping lax name lookup behavior a Python interop facilitator rather than a general language feature.</div><div><br></div><div>-Joe</div></body></html>