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