> On May 25, 2016, at 7:07 AM, Thorsten Seitz via swift-evolution > <swift-evolution@swift.org> wrote: > This is unfortunate, because then the meaning of "existential" and > "non-existential" in Swift are just the opposite of their respective meaning > in standard terminology :-(
I don't know what you mean by this. The standard terminology is that an existential type is one that's directly existentially-quantified, e.g. ∃ t . t, which is essentially what a Swift protocol type is: P ::= ∃ t : P . t P.Type ::= ∃ t : P . t.Type etc. Language operations then implicitly form (erasure) and break down (opening) those qualifiers in basically the same way that they implicitly break down the universal quantifiers on generic functions. If you're thinking about Haskell, Haskell's existential features are carefully tied to constructors and pattern-matching in part because erasure is a kind of implicit conversion, which would not fit cleanly into Haskell's type system. (Universal application also requires an implicit representation change, but that doesn't need to be reflected in H-M systems for technical reasons unless you're trying to support higher-rank polymorphism; I'm not up on the type-checking literature there.) John. > > -Thorsten > > > Am 25. Mai 2016 um 14:27 schrieb Brent Royal-Gordon <br...@architechies.com>: > >>> AFAIK an existential type is a type T with type parameters that are still >>> abstract (see for example >>> https://en.wikipedia.org/wiki/Type_system#Existential_types >>> <https://en.wikipedia.org/wiki/Type_system#Existential_types>), i.e. have >>> not been assigned concrete values. >> >> My understanding is that, in Swift, the instance used to store something >> whose concrete type is unknown (i.e. is still abstract), but which is known >> to conform to some protocol, is called an "existential". Protocols with >> associated values cannot be packed into normal existentials because, even >> though we know that the concrete type conforms to some protocol, the >> associated types represent additional unknowns, and Swift cannot be sure how >> to translate uses of those unknown types into callable members. Hence, >> protocols with associated types are sometimes called "non-existential". >> >> If I am misusing the terminology in this area, please understand that that's >> what I mean when I use that word. >> >> -- >> Brent Royal-Gordon >> Architechies >> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
