That makes sense. I can see how type providers are very handy for that. I’m just curious how they help with the goal that this proposal is intended to address: being able to use arbitrary Python APIs from Swift.
If the barrier to entry is the requirement for users to write type signatures for all APIs you want to use, then many will just immediately turn away at the gate. It also doesn’t appear to help *actually* dynamically polymorphic values, which occur in Python just like the occur in ObjC. Type providers seem like something that conceptually could be a useful refinement for my pitch: improving some APIs in some cases. I don’t see how it is a replacement, which seems to be what Joe was saying. -Chris > On Nov 11, 2017, at 2:17 PM, Alejandro Martinez <[email protected]> wrote: > > If it helps, for what I understand (in Typescript with things like > http://definitelytyped.org ) the idea with type providers is that > someone write the type definitions for dynamic code to basically > provide a more "typed" version of the API that can be consumed in a > more static language. > > On Sat, Nov 11, 2017 at 9:57 PM, Chris Lattner via swift-evolution > <[email protected]> wrote: >> >> >> On Nov 11, 2017, at 10:17 AM, Chris Lattner via swift-evolution >> <[email protected]> wrote: >> >> 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 >> >> >> 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. >> >> >> 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: >> >> 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? >> >> 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. >> >> 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”. >> >> 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! >> >> -Chris >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > > > -- > Alejandro Martinez > http://alejandromp.com _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
