The notion of types as sets of values and subtyping as a subset relation is
not quite so simple as it initially sounds. The issue is that unlike the
world of mathematics, programs aren't static and fixed forever. If we just
the subset notion at face value, we'd get this sort of thing:
abstract A
@assert A == Union{}
type B end
@assert A == Union{B} == B
type C end
@assert A == Union{B,C}
type D end
@assert A == Union{B,C,D}
Obviously that's not what we want. But at each point in time, A the set of
types that are subtypes of A is equal that union of concrete types. The
trouble is that the collection of subtypes of A can and does change over
time. And even if it were fixed for the duration of a particular version of
a program, as it would be in static language, we still wouldn't want A to
be equal to union of its subtypes because programs themselves evolve: if at
some point in the future, someone added a new subtype to A (and of course,
allowing that is the whole point of A being abstract in the first place),
then that introduction of a subtype would change previously valid assertion
about the identity of A, which is not good at all.
So the notion of subtyping as a subset relation must be more subtle than
sets of currently existing types. Instead, it's about about sets of
potential types: any union of concrete subtypes of A is a strict subtype of
A because the potential exists to add more subtypes of A. The identity of a
type is the set of potential values it *could* contain and a type is a
subtype of another if any value it could ever contain would also have to be
a value of the other type.
This is why returning a union of subtypes is weird, pointless and arguably
wrong. What is the meaning of that union? It's a snapshot that currently
has all of the same subtypes as A but may or may not in the future. What
are you going to do with this union? The only sane thing to do with it is
iterate over its contents to do something for each individual subtype *right
now* – treating it as an approximation of A is broken and incorrect for
exactly the reasons that we don't consider this union to be equal to A.
On Mon, Jan 4, 2016 at 11:32 PM, Ismael VC <[email protected]> wrote:
> Just my thoughts:
>
> - You can’t have Set{R, S} only Set{T}, Set{DataType}([R, S]) for
> example.
> - The moment you want to dispatch on those subtypes you would need to
> do something like Union{Ts...}, where Ts is an array or set of such
> subtypes.
> - Union{R, S} == Union{S, R} is true.
> - Base.length(u::Union) = length(u.types) for cardinality.
>
> It’s an interesting thought experiment! :D
>
>
> Ismael Venegas Castelló
>
> *Data Analyst*
>
> Cel. 044 55 6434 0229
>
> [email protected]
>
> Cerro San Francisco 357, C.P. 04200
>
> Campestre Churubusco, Coyoacán
>
> Ciudad de México
>
> <http://t.sidekickopen35.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XX43Mx_82W1p1tN-8q-fZWW3LPXXH56dKBHf5NSPJF02?t=https%3A%2F%2Frichit.com.mx%2F&si=4656540167962624&pi=2141b786-8886-4b07-84be-1a418b1636a4>
>
> <https://www.facebook.com/richitsolution>
> <http://t.sidekickopen35.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XX43Mx_82W1p1tN-8q-fZWW3LPXXH56dKBHf5NSPJF02?t=https%3A%2F%2Ftwitter.com%2Frichitsolution&si=4656540167962624&pi=2141b786-8886-4b07-84be-1a418b1636a4>
> <[email protected]>
>
> Tel. 6718 1818
> richit.com.mx
>
> 2016-01-04 21:04 GMT-06:00 Ray Toal <[email protected]>:
>
>> All good, but I just can't see it. If I have:
>>
>> julia> abstract T
>> julia> type S <: T; end
>> julia> type R <: T; end
>>
>> and I ask "What are the subtypes of T?" I would expect to get back either
>>
>> [S,R]
>>
>> or
>>
>> [R,S]
>>
>> or even
>>
>> Set{R,S}
>>
>> because each of those things have cardinality 2. Because there are 2
>> subsets of T. If instead I were to get back the value
>>
>> Union{R,S}
>>
>> then that would be answering the question "What are the subtypes of T?"
>> with the answer "This SINGLE type whose values are all the same as the
>> original type." That I **can't** understand (and would be surprised if Jeff
>> would), but if everyone else thinks it makes sense, no worries! We can
>> disagree. Our expectations might differ on this.
>>
>> I thought it was a fun thought experiment to begin with....
>>
>> Thanks for the discussion.
>>
>> On Monday, January 4, 2016 at 5:48:53 PM UTC-8, Ismael Venegas Castelló
>> wrote:
>>>
>>> After watching the video: *Jeff Bezanzon: Julia - The base language,
>>> future directions and speculations
>>> <https://www.youtube.com/watch?v=xUP3cSKb8sI> *as Scott mentions,
>>> returning a Union type indeed starts to make sense to me.
>>>
>>>
>>> El sábado, 2 de enero de 2016, 13:09:43 (UTC-6), Scott Jones escribió:
>>>>
>>>> Going by Jeff's JuliaCon 2015 talk, and the code in
>>>> examples/JuliaTypes.jl, I think returning the subtypes as a set of types
>>>> (which is the same as a union of types) makes perfect sense.
>>>> I'm hoping that this change does make it into 0.5, I think it does
>>>> clean up a lot of bad corner cases in the current type system (which Jeff
>>>> also mentioned in his talk)
>>>>
>>>> On Tuesday, December 29, 2015 at 5:45:51 PM UTC-5, Ray Toal wrote:
>>>>>
>>>>> But maybe I'm not understanding this correctly? Was it suggested that
>>>>> a type union be the result of the subtypes method? I don't think that
>>>>> makes
>>>>> sense.... The subtypes of a type is a set of types, not a type (even if
>>>>> that type were the union of all the subtypes). It strikes me as a little
>>>>> odd, but I may have misheard, or there might me an interpretation of it
>>>>> that I haven't thought about.
>>>>>
>>>>> On Tuesday, December 29, 2015 at 7:02:41 AM UTC-8, Scott Jones wrote:
>>>>>>
>>>>>> Yes! 😄 I was hoping that Jeff had implemented something super fast
>>>>>> for type unions.
>>>>>
>>>>>
>
