[swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

[Alejandro Martinez]

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 at swift.org> wrote:
>
>
> On Nov 11, 2017, at 10:17 AM, Chris Lattner via swift-evolution
> <swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Alejandro Martinez
http://alejandromp.com