Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Stefan Karpinski]

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  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
>
> ivene...@richit.com.mx
>
> Cerro San Francisco 357, C.P. 04200
>
> Campestre Churubusco, Coyoacán
>
> Ciudad de México
>
> 
>
> 
> 
>   
>
> Tel. 6718 1818
> richit.com.mx
>
> 2016-01-04 21:04 GMT-06:00 Ray Toal :
>
>> 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
>>>  *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 

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Stefan Karpinski]

Also as Ray pointed out, if subtypes returned a union, it would not be
returning a collection of types as the name would suggest but rather a
single type.

On Tue, Jan 5, 2016 at 9:42 AM, Stefan Karpinski 
wrote:

> 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 
> 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
>>
>> ivene...@richit.com.mx
>>
>> Cerro San Francisco 357, C.P. 04200
>>
>> Campestre Churubusco, Coyoacán
>>
>> Ciudad de México
>>
>> 
>>
>> 
>> 
>>   
>>
>> Tel. 6718 1818
>> richit.com.mx
>>
>> 2016-01-04 21:04 GMT-06:00 Ray Toal :
>>
>>> 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
  *as Scott mentions,
 

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Ray Toal]

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 
>  *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.
>>>
>>>

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Ismael VC]

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

ivene...@richit.com.mx

Cerro San Francisco 357, C.P. 04200

Campestre Churubusco, Coyoacán

Ciudad de México




  

Tel. 6718 1818
richit.com.mx

2016-01-04 21:04 GMT-06:00 Ray Toal :

> 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
>>  *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.

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Ismael Venegas Castelló]

After watching the video: *Jeff Bezanzon: Julia - The base language, future 
directions and speculations  *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.
>>
>>

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Scott Jones]

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.
>
>

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Ray Toal]

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.

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Mauro]

I think Scott meant a type union:

julia> Union{Int,Float64}
Union{Float64,Int64}

julia> Int<:ans
true

which is itself a type.

On Tue, 2015-12-29 at 00:53, Ismael VC  wrote:
> I thougt one advantage of using sets would be the ability to use set
> operations, but they work on arrays to, by the way the documentation of ie,
> union falls short, because it’s actually more general than what it says (*not
> only sets*):
>
> help?> union
> search: union union! Union @unix_only function Function functionloc 
> functionlocs
>
>   union(s1,s2...)
>   ∪(s1,s2...)
>
>   Construct the union of two or more sets. Maintains order with arrays.
>
> julia> union([1, 1], [2])# this also works!
> 2-element Array{Int64,1}:
>  1
>  2
>
>
>
> Ismael Venegas Castelló
>
> *Data Analyst*
>
> Cel. 044 55 6434 0229
>
> ivene...@richit.com.mx
>
> Cerro San Francisco 357, C.P. 04200
>
> Campestre Churubusco, Coyoacán
>
> Ciudad de México
> 
>
> 
> 
>   
>
> Tel. 6718 1818
> richit.com.mx
>
> 2015-12-28 12:44 GMT-06:00 Scott Jones :
>
>> How would this fit in with Jeff's work on types/subtypes?
>> At JuliaCon he did talk about improving the type system (something I've
>> been really hoping to see).
>> It seems to me that it might be more logically consistent to return a type
>> union for this, but I understand that currently it is easier to work with
>> returning a simple sorted vector.
>>
>> Scott
>>
>> On Sunday, December 27, 2015 at 12:10:38 AM UTC-5, Kevin Squire wrote:
>>>
>>>
>>>
>>> On Saturday, December 26, 2015, Ray Toal  wrote:
>>>
 I noticed that

 *julia> **subtypes(Type)*

 *3-element Array{Any,1}:*

 * DataType  *

 * TypeConstructor*

 * Union *

 and was wondering if there was any significance in the order of the
 subtypes. If not, could the method have produced a Set instead?


>>> It could, but why?  A set has a bit more overhead than an array, and for
>>> most types, the number of subtypes is small enough that sets wouldn't
>>> really offer any advantage.
>>>
>>> Is there something you want to do with the results that you think
>>> requires a set?
>>>
>>> Cheers,
>>> Kevin
>>>
>>

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Scott Jones]

How would this fit in with Jeff's work on types/subtypes?
At JuliaCon he did talk about improving the type system (something I've 
been really hoping to see).
It seems to me that it might be more logically consistent to return a type 
union for this, but I understand that currently it is easier to work with 
returning a simple sorted vector.

Scott

On Sunday, December 27, 2015 at 12:10:38 AM UTC-5, Kevin Squire wrote:
>
>
>
> On Saturday, December 26, 2015, Ray Toal  
> wrote:
>
>> I noticed that 
>>
>> *julia> **subtypes(Type)*
>>
>> *3-element Array{Any,1}:*
>>
>> * DataType  *
>>
>> * TypeConstructor*
>>
>> * Union *
>>
>> and was wondering if there was any significance in the order of the 
>> subtypes. If not, could the method have produced a Set instead?
>>
>>
> It could, but why?  A set has a bit more overhead than an array, and for 
> most types, the number of subtypes is small enough that sets wouldn't 
> really offer any advantage.
>
> Is there something you want to do with the results that you think requires 
> a set?
>
> Cheers,
> Kevin  
>

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Stefan Karpinski]

No, please don't spend time on this. We're not going to change this to
return a heavyweight data structure like a Set when a simple structure like
and Array will do. In mathematics sets are simpler than ordered
collections, but in programming languages the relationship is reversed. In
general data structures like Set are only used when they are necessary,
such as when you need O(1) checking for inclusion. Since there's no such
need here, an array is simpler and better.

On Mon, Dec 28, 2015 at 2:40 AM, Kevin Squire 
wrote:

> Hi Ray,
>
> You're probably the first person to make this observation. I can see your
> point, and I don't really have a strong argument or opinion, really--the
> main reason it's sorted is probably because it looks nicer--at least if I
> did write that code, that would  have been my reasoning.
>
> If you're up for it, you could change it to create a set and submit a pull
> request. No guarantees it gets accepted, but the likelihood increases
> significantly over not submitting one. :-)
>
> Cheers,
>Kevin
>
>
> On Sunday, December 27, 2015, Ray Toal  wrote:
>
>> I'm sure the order won't ever change, but I'd still find it odd if the
>> documentation of subtypes were to say
>>
>> "Returns a list of subtypes, sorted by the name of the subtype"
>>
>> because, well, what about namespaces? What about all sorts of Unicode
>> collation definitions that would have to be a part of such a definition?
>>
>> Yes, as much as I would like to just assert that the result of calling
>> subtypes on Type produces the array [DataType, TypeConstructor, Union] it's
>> just not supposed to be an array, even if today we can guarantee that the
>> array will be sorted, and it is ridiculously unlikely to change.
>>
>> I just think of unordered collections as sets. I don't think anyone would
>> or should ever write code that takes advantage of the fact that this array
>> is sorted, though. :)
>>
>> Thanks for the responses
>>
>> Ray
>>
>>
>> On Sunday, December 27, 2015 at 5:10:46 PM UTC-8, Kevin Squire wrote:
>>>
>>> Thanks for looking and posting (I've been on my phone).  I think I might
>>> have written that code, actually. ;-)
>>>
>>> Cheers!
>>>Kevin
>>>
>>> On Sunday, December 27, 2015, Ismael VC  wrote:
>>>
 Kevin I tested in my Win laptop with 0.3.11, 0.4.2, 0.4, 0.5+ also the
 same versions in julia box, and the output is deterministically sorted, It
 seems this has been the way it works for some time now, then I looked at
 the code and it’s indeed sorted (should have done that first! :P ):

- http://git.io/vEXL9

 subtypes(m::Module, x::DataType) = sort(collect(_subtypes(m, x)), 
 by=string)
 subtypes(x::DataType) = subtypes(Main, x)

 I would expect a very good reason in order to justify a change for this
 now.
 ​

 2015-12-27 18:06 GMT-06:00 Kevin Squire

> Ray, thanks for the clarification--makes sense. In fact, for
> introspection code like 'subtypes', performance is probably the wrong
> argument--it's unlikely that it occurs in performance-critical code. I
> think it's really that arrays are just simpler.
>
> One aesthetic change I could imagine would be to have the results
> sorted before returning, which would keep the same data structure, but
> solve your problem, and present the subtypes in a way the user would 
> likely
> find more useful.
>
> Ismael, it might be a little brittle to depend on the current order
> (unless it's always sorted now).
>
> Cheers,
>Kevin
>
>
> On Sunday, December 27, 2015, Ismael Venegas Castelló wrote:
>
>> You can just do:
>>
>> @assert subtypes(Type) == [DataType, TypeConstructor, Union]
>>
>> I just tested this:
>>
>> julia> @time for i in 1:1000
>>@assert subtypes(Type) == [DataType, TypeConstructor,
>> Union]
>>end
>>   3.025415 seconds (767.00 k allocations: 224.075 MB, 0.49% gc time)
>>
>>
>>
>> El sábado, 26 de diciembre de 2015, 12:52:51 (UTC-6), Ray Toal
>> escribió:
>>>
>>> I noticed that
>>>
>>> *julia> **subtypes(Type)*
>>>
>>> *3-element Array{Any,1}:*
>>>
>>> * DataType  *
>>>
>>> * TypeConstructor*
>>>
>>> * Union *
>>>
>>> and was wondering if there was any significance in the order of the
>>> subtypes. If not, could the method have produced a Set instead?
>>>
>>>

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Ismael Venegas Castelló]

Stefan, wouldn't using `sort!` instead of `sort` be better here in this 
case?:

subtypes(m::Module, x::DataType) = sort(collect(_subtypes(m, x)), by=string)

subtypes(m::Module, x::DataType) = sort!(collect(_subtypes(m, x)), 
by=string)



El lunes, 28 de diciembre de 2015, 9:25:08 (UTC-6), Stefan Karpinski 
escribió:
>
> No, please don't spend time on this. We're not going to change this to 
> return a heavyweight data structure like a Set when a simple structure like 
> and Array will do. In mathematics sets are simpler than ordered 
> collections, but in programming languages the relationship is reversed. In 
> general data structures like Set are only used when they are necessary, 
> such as when you need O(1) checking for inclusion. Since there's no such 
> need here, an array is simpler and better.
>
> On Mon, Dec 28, 2015 at 2:40 AM, Kevin Squire  > wrote:
>
>> Hi Ray,
>>
>> You're probably the first person to make this observation. I can see your 
>> point, and I don't really have a strong argument or opinion, really--the 
>> main reason it's sorted is probably because it looks nicer--at least if 
>> I did write that code, that would  have been my reasoning.
>>
>> If you're up for it, you could change it to create a set and submit a 
>> pull request. No guarantees it gets accepted, but the likelihood increases 
>> significantly over not submitting one. :-)
>>
>> Cheers,
>>Kevin 
>>
>>
>> On Sunday, December 27, 2015, Ray Toal  
>> wrote:
>>
>>> I'm sure the order won't ever change, but I'd still find it odd if the 
>>> documentation of subtypes were to say
>>>
>>> "Returns a list of subtypes, sorted by the name of the subtype"
>>>
>>> because, well, what about namespaces? What about all sorts of Unicode 
>>> collation definitions that would have to be a part of such a definition?
>>>
>>> Yes, as much as I would like to just assert that the result of calling 
>>> subtypes on Type produces the array [DataType, TypeConstructor, Union] it's 
>>> just not supposed to be an array, even if today we can guarantee that the 
>>> array will be sorted, and it is ridiculously unlikely to change.
>>>
>>> I just think of unordered collections as sets. I don't think anyone 
>>> would or should ever write code that takes advantage of the fact that this 
>>> array is sorted, though. :)
>>>
>>> Thanks for the responses
>>>
>>> Ray
>>>
>>>
>>> On Sunday, December 27, 2015 at 5:10:46 PM UTC-8, Kevin Squire wrote:

 Thanks for looking and posting (I've been on my phone).  I think I 
 might have written that code, actually. ;-)

 Cheers!
Kevin 

 On Sunday, December 27, 2015, Ismael VC  wrote:

> Kevin I tested in my Win laptop with 0.3.11, 0.4.2, 0.4, 0.5+ also the 
> same versions in julia box, and the output is deterministically sorted, 
> It 
> seems this has been the way it works for some time now, then I looked at 
> the code and it’s indeed sorted (should have done that first! :P ):
>
>- http://git.io/vEXL9 
>
> subtypes(m::Module, x::DataType) = sort(collect(_subtypes(m, x)), 
> by=string)
> subtypes(x::DataType) = subtypes(Main, x)
>
> I would expect a very good reason in order to justify a change for 
> this now.
> ​
>
> 2015-12-27 18:06 GMT-06:00 Kevin Squire
>
>> Ray, thanks for the clarification--makes sense. In fact, for 
>> introspection code like 'subtypes', performance is probably the wrong 
>> argument--it's unlikely that it occurs in performance-critical code. I 
>> think it's really that arrays are just simpler. 
>>
>> One aesthetic change I could imagine would be to have the results 
>> sorted before returning, which would keep the same data structure, but 
>> solve your problem, and present the subtypes in a way the user would 
>> likely 
>> find more useful.  
>>
>> Ismael, it might be a little brittle to depend on the current order 
>> (unless it's always sorted now).
>>
>> Cheers,
>>Kevin 
>>
>>
>> On Sunday, December 27, 2015, Ismael Venegas Castelló wrote:
>>
>>> You can just do:
>>>
>>> @assert subtypes(Type) == [DataType, TypeConstructor, Union]
>>>
>>> I just tested this:
>>>
>>> julia> @time for i in 1:1000
>>>@assert subtypes(Type) == [DataType, TypeConstructor, 
>>> Union]
>>>end
>>>   3.025415 seconds (767.00 k allocations: 224.075 MB, 0.49% gc time)
>>>
>>>
>>>
>>> El sábado, 26 de diciembre de 2015, 12:52:51 (UTC-6), Ray Toal 
>>> escribió:

 I noticed that 

 *julia> **subtypes(Type)*

 *3-element Array{Any,1}:*

 * DataType  *

 * TypeConstructor*

 * Union *

 and was wondering if there was any significance in the order 

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Stefan Karpinski]

Sure. That avoids unnecessarily copying the array.

On Mon, Dec 28, 2015 at 10:51 AM, Ismael Venegas Castelló <
ismael.vc1...@gmail.com> wrote:

> Stefan, wouldn't using `sort!` instead of `sort` be better here in this
> case?:
>
> subtypes(m::Module, x::DataType) = sort(collect(_subtypes(m, x)),
> by=string)
>
> subtypes(m::Module, x::DataType) = sort!(collect(_subtypes(m, x)),
> by=string)
>
>
>
> El lunes, 28 de diciembre de 2015, 9:25:08 (UTC-6), Stefan Karpinski
> escribió:
>>
>> No, please don't spend time on this. We're not going to change this to
>> return a heavyweight data structure like a Set when a simple structure like
>> and Array will do. In mathematics sets are simpler than ordered
>> collections, but in programming languages the relationship is reversed. In
>> general data structures like Set are only used when they are necessary,
>> such as when you need O(1) checking for inclusion. Since there's no such
>> need here, an array is simpler and better.
>>
>> On Mon, Dec 28, 2015 at 2:40 AM, Kevin Squire 
>> wrote:
>>
>>> Hi Ray,
>>>
>>> You're probably the first person to make this observation. I can see
>>> your point, and I don't really have a strong argument or opinion,
>>> really--the main reason it's sorted is probably because it looks
>>> nicer--at least if I did write that code, that would  have been my
>>> reasoning.
>>>
>>> If you're up for it, you could change it to create a set and submit a
>>> pull request. No guarantees it gets accepted, but the likelihood increases
>>> significantly over not submitting one. :-)
>>>
>>> Cheers,
>>>Kevin
>>>
>>>
>>> On Sunday, December 27, 2015, Ray Toal  wrote:
>>>
 I'm sure the order won't ever change, but I'd still find it odd if the
 documentation of subtypes were to say

 "Returns a list of subtypes, sorted by the name of the subtype"

 because, well, what about namespaces? What about all sorts of Unicode
 collation definitions that would have to be a part of such a definition?

 Yes, as much as I would like to just assert that the result of calling
 subtypes on Type produces the array [DataType, TypeConstructor, Union] it's
 just not supposed to be an array, even if today we can guarantee that the
 array will be sorted, and it is ridiculously unlikely to change.

 I just think of unordered collections as sets. I don't think anyone
 would or should ever write code that takes advantage of the fact that this
 array is sorted, though. :)

 Thanks for the responses

 Ray


 On Sunday, December 27, 2015 at 5:10:46 PM UTC-8, Kevin Squire wrote:
>
> Thanks for looking and posting (I've been on my phone).  I think I
> might have written that code, actually. ;-)
>
> Cheers!
>Kevin
>
> On Sunday, December 27, 2015, Ismael VC  wrote:
>
>> Kevin I tested in my Win laptop with 0.3.11, 0.4.2, 0.4, 0.5+ also
>> the same versions in julia box, and the output is deterministically 
>> sorted,
>> It seems this has been the way it works for some time now, then I looked 
>> at
>> the code and it’s indeed sorted (should have done that first! :P ):
>>
>>- http://git.io/vEXL9
>>
>> subtypes(m::Module, x::DataType) = sort(collect(_subtypes(m, x)), 
>> by=string)
>> subtypes(x::DataType) = subtypes(Main, x)
>>
>> I would expect a very good reason in order to justify a change for
>> this now.
>> ​
>>
>> 2015-12-27 18:06 GMT-06:00 Kevin Squire
>>
>>> Ray, thanks for the clarification--makes sense. In fact, for
>>> introspection code like 'subtypes', performance is probably the wrong
>>> argument--it's unlikely that it occurs in performance-critical code. I
>>> think it's really that arrays are just simpler.
>>>
>>> One aesthetic change I could imagine would be to have the results
>>> sorted before returning, which would keep the same data structure, but
>>> solve your problem, and present the subtypes in a way the user would 
>>> likely
>>> find more useful.
>>>
>>> Ismael, it might be a little brittle to depend on the current order
>>> (unless it's always sorted now).
>>>
>>> Cheers,
>>>Kevin
>>>
>>>
>>> On Sunday, December 27, 2015, Ismael Venegas Castelló wrote:
>>>
 You can just do:

 @assert subtypes(Type) == [DataType, TypeConstructor, Union]

 I just tested this:

 julia> @time for i in 1:1000
@assert subtypes(Type) == [DataType, TypeConstructor,
 Union]
end
   3.025415 seconds (767.00 k allocations: 224.075 MB, 0.49% gc time)



 El sábado, 26 de diciembre de 2015, 12:52:51 (UTC-6), Ray Toal
 escribió:
>
> I noticed that
>
> 

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Ismael VC]

Ok then I'll make a PR for that, and see if I find more uses like this that
can be changed.

Ismael Venegas Castelló

*Data Analyst*

Cel. 044 55 6434 0229

ivene...@richit.com.mx

Cerro San Francisco 357, C.P. 04200

Campestre Churubusco, Coyoacán

Ciudad de México




  

Tel. 6718 1818
richit.com.mx

2015-12-28 12:12 GMT-06:00 Stefan Karpinski :

> Sure. That avoids unnecessarily copying the array.
>
> On Mon, Dec 28, 2015 at 10:51 AM, Ismael Venegas Castelló <
> ismael.vc1...@gmail.com> wrote:
>
>> Stefan, wouldn't using `sort!` instead of `sort` be better here in this
>> case?:
>>
>> subtypes(m::Module, x::DataType) = sort(collect(_subtypes(m, x)),
>> by=string)
>>
>> subtypes(m::Module, x::DataType) = sort!(collect(_subtypes(m, x)),
>> by=string)
>>
>>
>>
>> El lunes, 28 de diciembre de 2015, 9:25:08 (UTC-6), Stefan Karpinski
>> escribió:
>>>
>>> No, please don't spend time on this. We're not going to change this to
>>> return a heavyweight data structure like a Set when a simple structure like
>>> and Array will do. In mathematics sets are simpler than ordered
>>> collections, but in programming languages the relationship is reversed. In
>>> general data structures like Set are only used when they are necessary,
>>> such as when you need O(1) checking for inclusion. Since there's no such
>>> need here, an array is simpler and better.
>>>
>>> On Mon, Dec 28, 2015 at 2:40 AM, Kevin Squire 
>>> wrote:
>>>
 Hi Ray,

 You're probably the first person to make this observation. I can see
 your point, and I don't really have a strong argument or opinion,
 really--the main reason it's sorted is probably because it looks
 nicer--at least if I did write that code, that would  have been my
 reasoning.

 If you're up for it, you could change it to create a set and submit a
 pull request. No guarantees it gets accepted, but the likelihood increases
 significantly over not submitting one. :-)

 Cheers,
Kevin


 On Sunday, December 27, 2015, Ray Toal  wrote:

> I'm sure the order won't ever change, but I'd still find it odd if the
> documentation of subtypes were to say
>
> "Returns a list of subtypes, sorted by the name of the subtype"
>
> because, well, what about namespaces? What about all sorts of Unicode
> collation definitions that would have to be a part of such a definition?
>
> Yes, as much as I would like to just assert that the result of calling
> subtypes on Type produces the array [DataType, TypeConstructor, Union
> ] it's just not supposed to be an array, even if today we can
> guarantee that the array will be sorted, and it is ridiculously unlikely 
> to
> change.
>
> I just think of unordered collections as sets. I don't think anyone
> would or should ever write code that takes advantage of the fact that this
> array is sorted, though. :)
>
> Thanks for the responses
>
> Ray
>
>
> On Sunday, December 27, 2015 at 5:10:46 PM UTC-8, Kevin Squire wrote:
>>
>> Thanks for looking and posting (I've been on my phone).  I think I
>> might have written that code, actually. ;-)
>>
>> Cheers!
>>Kevin
>>
>> On Sunday, December 27, 2015, Ismael VC  wrote:
>>
>>> Kevin I tested in my Win laptop with 0.3.11, 0.4.2, 0.4, 0.5+ also
>>> the same versions in julia box, and the output is deterministically 
>>> sorted,
>>> It seems this has been the way it works for some time now, then I 
>>> looked at
>>> the code and it’s indeed sorted (should have done that first! :P ):
>>>
>>>- http://git.io/vEXL9
>>>
>>> subtypes(m::Module, x::DataType) = sort(collect(_subtypes(m, x)), 
>>> by=string)
>>> subtypes(x::DataType) = subtypes(Main, x)
>>>
>>> I would expect a very good reason in order to justify a change for
>>> this now.
>>> ​
>>>
>>> 2015-12-27 18:06 GMT-06:00 Kevin Squire
>>>
 Ray, thanks for the clarification--makes sense. In fact, for
 introspection code like 'subtypes', performance is probably the wrong
 argument--it's unlikely that it occurs in performance-critical code. I
 think it's really that arrays are just simpler.

 One aesthetic change I could imagine would be to have the results
 sorted before 

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Ismael VC]

I thougt one advantage of using sets would be the ability to use set
operations, but they work on arrays to, by the way the documentation of ie,
union falls short, because it’s actually more general than what it says (*not
only sets*):

help?> union
search: union union! Union @unix_only function Function functionloc functionlocs

  union(s1,s2...)
  ∪(s1,s2...)

  Construct the union of two or more sets. Maintains order with arrays.

julia> union([1, 1], [2])# this also works!
2-element Array{Int64,1}:
 1
 2

​

Ismael Venegas Castelló

*Data Analyst*

Cel. 044 55 6434 0229

ivene...@richit.com.mx

Cerro San Francisco 357, C.P. 04200

Campestre Churubusco, Coyoacán

Ciudad de México




  

Tel. 6718 1818
richit.com.mx

2015-12-28 12:44 GMT-06:00 Scott Jones :

> How would this fit in with Jeff's work on types/subtypes?
> At JuliaCon he did talk about improving the type system (something I've
> been really hoping to see).
> It seems to me that it might be more logically consistent to return a type
> union for this, but I understand that currently it is easier to work with
> returning a simple sorted vector.
>
> Scott
>
> On Sunday, December 27, 2015 at 12:10:38 AM UTC-5, Kevin Squire wrote:
>>
>>
>>
>> On Saturday, December 26, 2015, Ray Toal  wrote:
>>
>>> I noticed that
>>>
>>> *julia> **subtypes(Type)*
>>>
>>> *3-element Array{Any,1}:*
>>>
>>> * DataType  *
>>>
>>> * TypeConstructor*
>>>
>>> * Union *
>>>
>>> and was wondering if there was any significance in the order of the
>>> subtypes. If not, could the method have produced a Set instead?
>>>
>>>
>> It could, but why?  A set has a bit more overhead than an array, and for
>> most types, the number of subtypes is small enough that sets wouldn't
>> really offer any advantage.
>>
>> Is there something you want to do with the results that you think
>> requires a set?
>>
>> Cheers,
>> Kevin
>>
>

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Ray Toal]

Ah, I didn't think about performance. I was simply thinking that sets make 
more sense semantically when the order does not matter, and arrays or lists 
make sense when the order does matter. I thought there would be no point in 
using an array for unordered items, but it sounds like the point is 
performance.

I was putting together some instructional materials on Julia for a class 
and wanted to show off subtypes. I prefer writing demo code with asserts 
rather than prints, so I thought about writing

@assert subtypes(Type) == [DataType, TypeConstructor, Union]

However this is not reliable because the order is actually arbitrary. So I 
have to write

@assert Set(subtypes(Type)) == Set([DataType, TypeConstructor, Union])

which is ugly and would have been simpler if subtypes just returned a set 
in the first place!

Granted this is a minor nitpick because no one writing _real_ code would 
likely need to write a unit test asserting the value of the subtypes 
collection. Even if they did, I suppose they could make sets themselves.

Anyway, it just strikes me as weird to use an ordered collection where no 
order is implied. It's just yucky to me, but I will happily buy the 
performance argument (and perhaps a simplicity one, too, since sets require 
syntactic overhead as well!).

Thanks

Ray

On Saturday, December 26, 2015 at 9:10:38 PM UTC-8, Kevin Squire wrote:
>
>
>
> On Saturday, December 26, 2015, Ray Toal  
> wrote:
>
>> I noticed that 
>>
>> *julia> **subtypes(Type)*
>>
>> *3-element Array{Any,1}:*
>>
>> * DataType  *
>>
>> * TypeConstructor*
>>
>> * Union *
>>
>> and was wondering if there was any significance in the order of the 
>> subtypes. If not, could the method have produced a Set instead?
>>
>>
> It could, but why?  A set has a bit more overhead than an array, and for 
> most types, the number of subtypes is small enough that sets wouldn't 
> really offer any advantage.
>
> Is there something you want to do with the results that you think requires 
> a set?
>
> Cheers,
> Kevin  
>

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Ismael VC]

Kevin I tested in my Win laptop with 0.3.11, 0.4.2, 0.4, 0.5+ also the same
versions in julia box, and the output is deterministically sorted, It seems
this has been the way it works for some time now, then I looked at the code
and it’s indeed sorted (should have done that first! :P ):

   - http://git.io/vEXL9

subtypes(m::Module, x::DataType) = sort(collect(_subtypes(m, x)), by=string)
subtypes(x::DataType) = subtypes(Main, x)

I would expect a very good reason in order to justify a change for this now.
​

Ismael Venegas Castelló

*Data Analyst*

Cel. 044 55 6434 0229

ivene...@richit.com.mx

Cerro San Francisco 357, C.P. 04200

Campestre Churubusco, Coyoacán

Ciudad de México




  

Tel. 6718 1818
richit.com.mx

2015-12-27 18:06 GMT-06:00 Kevin Squire :

> Ray, thanks for the clarification--makes sense. In fact, for introspection
> code like 'subtypes', performance is probably the wrong argument--it's
> unlikely that it occurs in performance-critical code. I think it's really
> that arrays are just simpler.
>
> One aesthetic change I could imagine would be to have the results sorted
> before returning, which would keep the same data structure, but solve your
> problem, and present the subtypes in a way the user would likely find more
> useful.
>
> Ismael, it might be a little brittle to depend on the current order
> (unless it's always sorted now).
>
> Cheers,
>Kevin
>
>
> On Sunday, December 27, 2015, Ismael Venegas Castelló <
> ismael.vc1...@gmail.com> wrote:
>
>> You can just do:
>>
>> @assert subtypes(Type) == [DataType, TypeConstructor, Union]
>>
>> I just tested this:
>>
>> julia> @time for i in 1:1000
>>@assert subtypes(Type) == [DataType, TypeConstructor, Union]
>>end
>>   3.025415 seconds (767.00 k allocations: 224.075 MB, 0.49% gc time)
>>
>>
>>
>> El sábado, 26 de diciembre de 2015, 12:52:51 (UTC-6), Ray Toal escribió:
>>>
>>> I noticed that
>>>
>>> *julia> **subtypes(Type)*
>>>
>>> *3-element Array{Any,1}:*
>>>
>>> * DataType  *
>>>
>>> * TypeConstructor*
>>>
>>> * Union *
>>>
>>> and was wondering if there was any significance in the order of the
>>> subtypes. If not, could the method have produced a Set instead?
>>>
>>>

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Kevin Squire]

Ray, thanks for the clarification--makes sense. In fact, for introspection
code like 'subtypes', performance is probably the wrong argument--it's
unlikely that it occurs in performance-critical code. I think it's really
that arrays are just simpler.

One aesthetic change I could imagine would be to have the results sorted
before returning, which would keep the same data structure, but solve your
problem, and present the subtypes in a way the user would likely find more
useful.

Ismael, it might be a little brittle to depend on the current order (unless
it's always sorted now).

Cheers,
   Kevin

On Sunday, December 27, 2015, Ismael Venegas Castelló <
ismael.vc1...@gmail.com> wrote:

> You can just do:
>
> @assert subtypes(Type) == [DataType, TypeConstructor, Union]
>
> I just tested this:
>
> julia> @time for i in 1:1000
>@assert subtypes(Type) == [DataType, TypeConstructor, Union]
>end
>   3.025415 seconds (767.00 k allocations: 224.075 MB, 0.49% gc time)
>
>
>
> El sábado, 26 de diciembre de 2015, 12:52:51 (UTC-6), Ray Toal escribió:
>>
>> I noticed that
>>
>> *julia> **subtypes(Type)*
>>
>> *3-element Array{Any,1}:*
>>
>> * DataType  *
>>
>> * TypeConstructor*
>>
>> * Union *
>>
>> and was wondering if there was any significance in the order of the
>> subtypes. If not, could the method have produced a Set instead?
>>
>>

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Kevin Squire]

Thanks for looking and posting (I've been on my phone).  I think I might
have written that code, actually. ;-)

Cheers!
   Kevin

On Sunday, December 27, 2015, Ismael VC  wrote:

> Kevin I tested in my Win laptop with 0.3.11, 0.4.2, 0.4, 0.5+ also the
> same versions in julia box, and the output is deterministically sorted, It
> seems this has been the way it works for some time now, then I looked at
> the code and it’s indeed sorted (should have done that first! :P ):
>
>- http://git.io/vEXL9
>
> subtypes(m::Module, x::DataType) = sort(collect(_subtypes(m, x)), by=string)
> subtypes(x::DataType) = subtypes(Main, x)
>
> I would expect a very good reason in order to justify a change for this
> now.
> ​
>
> Ismael Venegas Castelló
>
> *Data Analyst*
>
> Cel. 044 55 6434 0229
>
> ivene...@richit.com.mx
> 
>
> Cerro San Francisco 357, C.P. 04200
>
> Campestre Churubusco, Coyoacán
>
> Ciudad de México
>
> 
>
> 
> 
>   
>
> Tel. 6718 1818
> richit.com.mx
>
> 2015-12-27 18:06 GMT-06:00 Kevin Squire  >:
>
>> Ray, thanks for the clarification--makes sense. In fact, for
>> introspection code like 'subtypes', performance is probably the wrong
>> argument--it's unlikely that it occurs in performance-critical code. I
>> think it's really that arrays are just simpler.
>>
>> One aesthetic change I could imagine would be to have the results sorted
>> before returning, which would keep the same data structure, but solve your
>> problem, and present the subtypes in a way the user would likely find more
>> useful.
>>
>> Ismael, it might be a little brittle to depend on the current order
>> (unless it's always sorted now).
>>
>> Cheers,
>>Kevin
>>
>>
>> On Sunday, December 27, 2015, Ismael Venegas Castelló <
>> ismael.vc1...@gmail.com
>> > wrote:
>>
>>> You can just do:
>>>
>>> @assert subtypes(Type) == [DataType, TypeConstructor, Union]
>>>
>>> I just tested this:
>>>
>>> julia> @time for i in 1:1000
>>>@assert subtypes(Type) == [DataType, TypeConstructor, Union]
>>>end
>>>   3.025415 seconds (767.00 k allocations: 224.075 MB, 0.49% gc time)
>>>
>>>
>>>
>>> El sábado, 26 de diciembre de 2015, 12:52:51 (UTC-6), Ray Toal escribió:

 I noticed that

 *julia> **subtypes(Type)*

 *3-element Array{Any,1}:*

 * DataType  *

 * TypeConstructor*

 * Union *

 and was wondering if there was any significance in the order of the
 subtypes. If not, could the method have produced a Set instead?


>

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Ray Toal]

I'm sure the order won't ever change, but I'd still find it odd if the 
documentation of subtypes were to say

"Returns a list of subtypes, sorted by the name of the subtype"

because, well, what about namespaces? What about all sorts of Unicode 
collation definitions that would have to be a part of such a definition?

Yes, as much as I would like to just assert that the result of calling 
subtypes on Type produces the array [DataType, TypeConstructor, Union] it's 
just not supposed to be an array, even if today we can guarantee that the 
array will be sorted, and it is ridiculously unlikely to change.

I just think of unordered collections as sets. I don't think anyone would 
or should ever write code that takes advantage of the fact that this array 
is sorted, though. :)

Thanks for the responses

Ray


On Sunday, December 27, 2015 at 5:10:46 PM UTC-8, Kevin Squire wrote:
>
> Thanks for looking and posting (I've been on my phone).  I think I might 
> have written that code, actually. ;-)
>
> Cheers!
>Kevin 
>
> On Sunday, December 27, 2015, Ismael VC  
> wrote:
>
>> Kevin I tested in my Win laptop with 0.3.11, 0.4.2, 0.4, 0.5+ also the 
>> same versions in julia box, and the output is deterministically sorted, It 
>> seems this has been the way it works for some time now, then I looked at 
>> the code and it’s indeed sorted (should have done that first! :P ):
>>
>>- http://git.io/vEXL9 
>>
>> subtypes(m::Module, x::DataType) = sort(collect(_subtypes(m, x)), by=string)
>> subtypes(x::DataType) = subtypes(Main, x)
>>
>> I would expect a very good reason in order to justify a change for this 
>> now.
>> ​
>>
>> 2015-12-27 18:06 GMT-06:00 Kevin Squire
>>
>>> Ray, thanks for the clarification--makes sense. In fact, for 
>>> introspection code like 'subtypes', performance is probably the wrong 
>>> argument--it's unlikely that it occurs in performance-critical code. I 
>>> think it's really that arrays are just simpler. 
>>>
>>> One aesthetic change I could imagine would be to have the results sorted 
>>> before returning, which would keep the same data structure, but solve your 
>>> problem, and present the subtypes in a way the user would likely find more 
>>> useful.  
>>>
>>> Ismael, it might be a little brittle to depend on the current order 
>>> (unless it's always sorted now).
>>>
>>> Cheers,
>>>Kevin 
>>>
>>>
>>> On Sunday, December 27, 2015, Ismael Venegas Castelló wrote:
>>>
 You can just do:

 @assert subtypes(Type) == [DataType, TypeConstructor, Union]

 I just tested this:

 julia> @time for i in 1:1000
@assert subtypes(Type) == [DataType, TypeConstructor, Union]
end
   3.025415 seconds (767.00 k allocations: 224.075 MB, 0.49% gc time)



 El sábado, 26 de diciembre de 2015, 12:52:51 (UTC-6), Ray Toal escribió:
>
> I noticed that 
>
> *julia> **subtypes(Type)*
>
> *3-element Array{Any,1}:*
>
> * DataType  *
>
> * TypeConstructor*
>
> * Union *
>
> and was wondering if there was any significance in the order of the 
> subtypes. If not, could the method have produced a Set instead?
>
>
>>

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Kevin Squire]

Hi Ray,

You're probably the first person to make this observation. I can see your
point, and I don't really have a strong argument or opinion, really--the
main reason it's sorted is probably because it looks nicer--at least if I
did write that code, that would  have been my reasoning.

If you're up for it, you could change it to create a set and submit a pull
request. No guarantees it gets accepted, but the likelihood increases
significantly over not submitting one. :-)

Cheers,
   Kevin

On Sunday, December 27, 2015, Ray Toal  wrote:

> I'm sure the order won't ever change, but I'd still find it odd if the
> documentation of subtypes were to say
>
> "Returns a list of subtypes, sorted by the name of the subtype"
>
> because, well, what about namespaces? What about all sorts of Unicode
> collation definitions that would have to be a part of such a definition?
>
> Yes, as much as I would like to just assert that the result of calling
> subtypes on Type produces the array [DataType, TypeConstructor, Union] it's
> just not supposed to be an array, even if today we can guarantee that the
> array will be sorted, and it is ridiculously unlikely to change.
>
> I just think of unordered collections as sets. I don't think anyone would
> or should ever write code that takes advantage of the fact that this array
> is sorted, though. :)
>
> Thanks for the responses
>
> Ray
>
>
> On Sunday, December 27, 2015 at 5:10:46 PM UTC-8, Kevin Squire wrote:
>>
>> Thanks for looking and posting (I've been on my phone).  I think I might
>> have written that code, actually. ;-)
>>
>> Cheers!
>>Kevin
>>
>> On Sunday, December 27, 2015, Ismael VC  wrote:
>>
>>> Kevin I tested in my Win laptop with 0.3.11, 0.4.2, 0.4, 0.5+ also the
>>> same versions in julia box, and the output is deterministically sorted, It
>>> seems this has been the way it works for some time now, then I looked at
>>> the code and it’s indeed sorted (should have done that first! :P ):
>>>
>>>- http://git.io/vEXL9
>>>
>>> subtypes(m::Module, x::DataType) = sort(collect(_subtypes(m, x)), by=string)
>>> subtypes(x::DataType) = subtypes(Main, x)
>>>
>>> I would expect a very good reason in order to justify a change for this
>>> now.
>>> ​
>>>
>>> 2015-12-27 18:06 GMT-06:00 Kevin Squire
>>>
 Ray, thanks for the clarification--makes sense. In fact, for
 introspection code like 'subtypes', performance is probably the wrong
 argument--it's unlikely that it occurs in performance-critical code. I
 think it's really that arrays are just simpler.

 One aesthetic change I could imagine would be to have the results
 sorted before returning, which would keep the same data structure, but
 solve your problem, and present the subtypes in a way the user would likely
 find more useful.

 Ismael, it might be a little brittle to depend on the current order
 (unless it's always sorted now).

 Cheers,
Kevin


 On Sunday, December 27, 2015, Ismael Venegas Castelló wrote:

> You can just do:
>
> @assert subtypes(Type) == [DataType, TypeConstructor, Union]
>
> I just tested this:
>
> julia> @time for i in 1:1000
>@assert subtypes(Type) == [DataType, TypeConstructor, Union]
>end
>   3.025415 seconds (767.00 k allocations: 224.075 MB, 0.49% gc time)
>
>
>
> El sábado, 26 de diciembre de 2015, 12:52:51 (UTC-6), Ray Toal
> escribió:
>>
>> I noticed that
>>
>> *julia> **subtypes(Type)*
>>
>> *3-element Array{Any,1}:*
>>
>> * DataType  *
>>
>> * TypeConstructor*
>>
>> * Union *
>>
>> and was wondering if there was any significance in the order of the
>> subtypes. If not, could the method have produced a Set instead?
>>
>>
>>>

[julia-users] Why does the subtypes method produce an array rather than a set?

[Ray Toal]

I noticed that 

*julia> **subtypes(Type)*

*3-element Array{Any,1}:*

* DataType  *

* TypeConstructor*

* Union *

and was wondering if there was any significance in the order of the 
subtypes. If not, could the method have produced a Set instead?

Re: [julia-users] Why does the subtypes method produce an array rather than a set?

[Kevin Squire]

On Saturday, December 26, 2015, Ray Toal  wrote:

> I noticed that
>
> *julia> **subtypes(Type)*
>
> *3-element Array{Any,1}:*
>
> * DataType  *
>
> * TypeConstructor*
>
> * Union *
>
> and was wondering if there was any significance in the order of the
> subtypes. If not, could the method have produced a Set instead?
>
>
It could, but why?  A set has a bit more overhead than an array, and for
most types, the number of subtypes is small enough that sets wouldn't
really offer any advantage.

Is there something you want to do with the results that you think requires
a set?

Cheers,
Kevin