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 <swift-evolution@swift.org> wrote: > > > On Nov 11, 2017, at 10:17 AM, Chris Lattner via swift-evolution > <swift-evolution@swift.org> 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > -- Alejandro Martinez http://alejandromp.com _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution