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 > <toiv...@gmail.com<javascript:> > > 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. >> >> >