That is weird and may be a dispatch bug. Perhaps an issue should be opened.
On Sun, Jan 26, 2014 at 3:00 PM, Toivo Henningsson <[email protected]>wrote: > The type of a type would e.g. describe which values are legal as the > second argument of isa. > It turns out that Type almost works. If I do > > julia> f(::Any)=false > > f (generic function with 1 method) > > > julia> f(::Type)=true > f (generic function with 2 methods) > > Then > > julia> f(Int) > true > > julia> f((Int,String)) > true > > julia> f((Int,String,2)) > false > > julia> [f(T) for T in (UnionType, DataType, TypeVar, TypeConstructor)]' > 1x4 Array{Bool,2}: > true true true true > > But it doesn't seem to catch all types: > > julia> f((Int,)) > false > > julia> f(((Int,String),String)) > false > > julia> f(((Int,String),String,Int)) > false > > On the other hand, this definition seems to catch all the cases that I > could come up with: > > julia> g(::Any)=false > > g (generic function with 1 method) > > > julia> g{T}(::Type{T}) = true > g (generic function with 2 methods) > > julia> g((Int,)) > true > > julia> g(((Int,String),String)) > true > > It is pretty weird that adding the type parameter makes the method that > returns true more general (I guess that I should file an issue...) > > Anyway, if the type of a tuple were <: Type and not <: Tuple, then these > things would not be hairy at all, since you wouldn't have to discern > between tuples that are types and tuples that aren't, and being a type > would behave as plainly as other subtyping relationships. > > > On Sunday, 26 January 2014 16:44:37 UTC+1, Leah Hanson wrote: > >> What do you mean by "the type of a type"? >> >> I wanted recently to be able to write a type annotation that would cover >> all the types of all the arguments to (exported) functions in Base. The >> following currently works: >> >> ~~~ >> Types = Union(DataType,UnionType,TypeVar,TypeConstructor,()) >> AtomicType = Union(Types,(Types,)) >> AType = Union(AtomicType,(AtomicType,), >> (AtomicType,AtomicType), >> (AtomicType,AtomicType,AtomicType), >> (AtomicType,AtomicType,AtomicType,AtomicType), >> (AtomicType,AtomicType,AtomicType,AtomicType,AtomicType), >> (AtomicType,AtomicType,AtomicType,AtomicType, >> AtomicType,AtomicType), >> (AtomicType,AtomicType,AtomicType,AtomicType, >> AtomicType,AtomicType,AtomicType)) >> ~~~ >> >> where AType is the type actually used to annotate. >> >> Tuple{Int,Int} would not help at all with specifying a type that covers >> all types, since I'd still need Tuple{AtomicType}, >> Tuple{Tuple{AtomicType}}, Tuple{AtomicType,AtomicType}, etc. >> >> -- Leah >> >> >> On Sun, Jan 26, 2014 at 7:51 AM, Toivo Henningsson <[email protected]>wrote: >> >>> >>> >>> On Saturday, 25 January 2014 18:36:59 UTC+1, David Piepgrass wrote: >>>> >>>> >>>> 3. Julia has first class types, so types are values in the language. >>>>> Tuple types are written as a tuple of the types, which seems fairly >>>>> straight-forward. Your version, Tuple{Int,Int}, would require a new type >>>>> for each size of tuple (or would have a different representation than you >>>>> suggested). I don't understand what you would gain by having a separate >>>>> type that basically reimplements the same functionality as a tuple. Could >>>>> you offer a concrete example of a problem this could cause? >>>>> >>>> >>>> The point is that a tuple is sometimes a type-of-type and other times >>>> it is just an ordinary value. So if there were a superclass of all types of >>>> types (as is the case in most languages with reflection), some tuples would >>>> be subclasses of it and others would not be. It's just ... so ... weird. >>>> I'm not claiming it's problematic, I'm *asking* if it is ever >>>> problematic. >>>> >>> >>> It is actually a bit problematic, occasionally. The Tuple{Int,Int} >>> variant has been mentioned at some point in the discussion, a good while >>> back. >>> It probably doesn't come up very often in practice, but at least for me >>> who does a lot of metaprogramming, I have sometimes had to work around the >>> fact that I can't specify the type of a type. I think that this is >>> something that would be nice to fix, but my impression is that it's pretty >>> low priority and possibly not considered to be worth the investment. >>> >>> >>
