This was stranger than I thought, seem to depend on the order of invocations to f. Issue filed: https://github.com/JuliaLang/julia/issues/5577
On Monday, 27 January 2014 18:21:56 UTC+1, Stefan Karpinski wrote: > > 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]<javascript:> > > 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. >>>> >>>> >>> >
