> On Nov 11, 2017, at 1:57 PM, Chris Lattner <clatt...@nondot.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!
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.
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.
-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
