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