> Le 1 déc. 2017 à 00:54, Xiaodi Wu via swift-evolution
> <[email protected]> a écrit :
>
> As I wrote in the earlier thread, I think this is the wrong way to reason
> about the use case--and a counterproductive one that effectively rejects the
> legitimacy of dynamic language interop support instead of working towards an
> optimal solution for it. Along those lines, some replies to your message
> literally question whether the user case is worthwhile to support at all,
> which I think entirely misses the mark.
>
> As Chris writes in his proposal, there are several areas (such as data
> science) where, to put it plainly, Python or another dynamic language is
> significantly better than Swift due to a much larger ecosystem of libraries,
> tools, and user communities, with sometimes decades of lead time. It is
> nonsensical to talk about how Swift is "supposed to be better" in any way
> whatsoever in that context. As diehard Swift users, we may be confident that
> the virtues of Swift's syntax, static typing, compiler smarts, protocol-based
> design, or whatever else offer opportunities for, say, data science libraries
> and tools to be better in the future, eventually. But to make this even
> possible involves first making Swift a viable language in which to work with
> current data science tools. Your top bullet point here reasons that one key
> flaw of Chris's proposal is that he has not somehow figured out how to make
> dynamic Python calls give compile-time Swift errors. If this is the minimum
> bar for Python interop, then as far as I can tell, it seems isomorphic to
> rejecting interop with dynamic languages altogether.
Hello, I agree with this reasoning.
Unless I miss the point, I see C. Lattner's proposals, function calls and
member lookup, as a very restricted interface to dynamic languages. They do
not aim at embedding dynamic languages into Swift at all, and let users write
long Python/Ruby/JS programs in Swift.
For example, "real" python would need list comprehension, generators,
async/await, etc. Such features are clearly out of scope of the proposals.
We can thus expect serious programs that use those features to process in three
steps: 1 turn Swift values in foreign values, 2. process foreign values with a
restricted foreign API, 3. turn computed foreign values into Swift values. It's
all about using good tools when needed.
In this context, I too am concerned with retroactive conformance. If it were
forbidden, it would make it very clear where the dynamic scope starts and ends:
// Input
let swiftInt: Int = 12
// Enter Python
let pyInt = Python.Value(swiftInt)
// Python code
let pyResult = pyInt.someFunc()
// Back to Swift
if let swiftResult = Int(pyResult) {
// proceed
}
Gwendal Roué
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
