More about types¶

Types and sets (and Any and Union{}/Bottom)¶

It’s perhaps easiest to conceive of Julia’s type system in terms of sets. A concrete type corresponds to a single entity in the space of all possible types; an abstract type refers to a collection (set) of concrete types. Any is a type that describes the entire universe of possible types; Integer is a subset of Any that includes Int, Int8, and other concrete types. Internally, Julia also makes heavy use of another type known as Bottom, or equivalently, Union{}. This corresponds to the empty set.

Julia’s types support the standard operations of set theory: you can ask whether T1 is a “subset” (subtype) of T2 with T1<:T2. Likewise, you intersect two types using typeintersect, take their union with Union, and compute a type that contains their union with typejoin:

julia>typeintersect(Int,Float64)Union{}julia>Union{Int,Float64}Union{Float64,Int64}julia>typejoin(Int,Float64)Realjulia>typeintersect(Signed,Union{UInt8,Int8})Int8julia>Union{Signed,Union{UInt8,Int8}}Union{Signed,UInt8}julia>typejoin(Signed,Union{UInt8,Int8})Integerjulia>typeintersect(Tuple{Integer,Float64},Tuple{Int,Real})Tuple{Int64,Float64}julia>Union{Tuple{Integer,Float64},Tuple{Int,Real}}Union{Tuple{Int64,Real},Tuple{Integer,Float64}}julia>typejoin(Tuple{Integer,Float64},Tuple{Int,Real})Tuple{Integer,Real}

While these operations may seem abstract, they lie at the heart of Julia. For example, method dispatch is implemented by stepping through the items in a method list until reaching one for which typeintersect(args,sig) is not Union{}. (Here, args is a tuple-type describing the types of the arguments, and sig is a tuple-type specifying the types in the function’s signature.) For this algorithm to work, it’s important that methods be sorted by their specificity, and that the search begins with the most specific methods. Consequently, Julia also implements a partial order on types; this is achieved by functionality that is similar to <:, but with differences that will be discussed below.

TypeVars¶

Many types take parameters; an easy example is Array, which takes two parameters often written as Array{T,N}. Let’s compare the following methods:

f1(A::Array)=1f2(A::Array{Int})=2f3{T}(A::Array{T})=3f4(A::Array{Any})=4f5{T<:Any}(A::Array{T})=5

All but f4 can be called with a=[1,2]; all but f2 can be called with b=Any[1,2].

Let’s look at these types a little more closely:

julia>ArrayArray{T,N}julia>xdump(Array)Array{T,N}::DataType<:DenseArray{T,N}

This indicates that Array is a shorthand for Array{T,N}. If you type this at the REPL prompt—on its own, not while defining a function or type—you get an error Tnotdefined. So what, exactly, are T and N? You can learn more by extracting these parameters:

julia>T,N=Array.parameterssvec(T,N)julia>xdump(T)TypeVarname:SymbolTlb:Union{}ub:Any::DataType<:Anybound:Boolfalse

A TypeVar is one of Julia’s built-in types—it’s defined in jltypes.c, although you can find a commented-out version in boot.jl. The name field is straightforward: it’s what’s printed when showing the object. lb and ub stand for “lower bound” and “upper bound,” respectively: these are the sets that constrain what types the TypeVar may represent. In this case, T‘s lower bound is Union{} (i.e., Bottom or the empty set); in other words, this TypeVar is not constrained from below. The upper bound is Any, so neither is it constrained from above.

In a method definition like:

g{S<:Integer}(x::S)=0

one can extract the underlying TypeVar:

g{S<:Integer}(x::S)=0m=start(methods(g))p=m.sig.parameterstv=p[1]xdump(tv)

TypeVar
  name: Symbol S
  lb: Union{}
  ub: Integer::DataType  <: Real
  bound: Bool true

Here ub is Integer, as specified in the function definition.

The last field of a TypeVar is bound. This boolean value specifies whether the TypeVar is defined as one of the function parameters. For example:

julia>h1(A::Array,b::Real)=1h1(genericfunction with1method)julia>h2{T<:Real}(A::Array,b::T)=1h2(genericfunction with1method)julia>h3{T<:Real}(A::Array{T},b::T)=1h3(genericfunction with1method)julia>p1=start(methods(h1)).sig.parameterssvec(Array{T,N},Real)julia>p2=start(methods(h2)).sig.parameterssvec(Array{T,N},T<:Real)julia>p3=start(methods(h3)).sig.parameterssvec(Array{T<:Real,N},T<:Real)julia>xdump(p1[1].parameters[1])TypeVarname:SymbolTlb:Union{}ub:Any::DataType<:Anybound:Boolfalsejulia>xdump(p3[1].parameters[1])TypeVarname:SymbolTlb:Union{}ub:Real::DataType<:Numberbound:Booltrue

Note that p2 shows two objects called T, but only one of them has the upper bound Real; in contrast, p3 shows both of them bounded. This is because in h3, the same type T is used in both places, whereas for h2 the T inside the array is simply the default symbol used for the first parameter of Array.

One can construct TypeVars manually:

julia>TypeVar(:V,Signed,Real,false)Signed<:V<:Real

There are convenience versions that allow you to omit any of these arguments except the name symbol.

Armed with this information, we can do some sneaky things that reveal a lot about how Julia does dispatch:

julia>TV=TypeVar(:T,false)# bound = falseTjulia>candid{T}(A::Array{T},x::T)=0candid(genericfunction with1method)julia>@evalsneaky{T}(A::Array{T},x::$TV)=1sneaky(genericfunction with1method)julia>methods(candid)# 1 method for generic function "candid":candid{T}(A::Array{T,N},x::T)atnone:1julia>methods(sneaky)# 1 method for generic function "sneaky":sneaky{T}(A::Array{T,N},x::T)atnone:1

These therefore print identically, but they have very different behavior:

julia>candid([1],3.2)ERROR:MethodError:`candid`hasnomethodmatchingcandid(::Array{Int64,1},::Float64)Closestcandidatesare:candid{T}(::Array{T,N},!Matched::T)julia>sneaky([1],3.2)1

To see what’s happening, it’s helpful to use Julia’s internal jl_() function (defined in builtins.c) for display, because it prints bound TypeVar objects with a hash (#T instead of T):

julia>jl_(x)=ccall(:jl_,Void,(Any,),x)jl_(genericfunction with1method)

julia>jl_(start(methods(candid)))Method(sig=Tuple{Array{#T<:Any, N<:Any}, #T<:Any}, va=false, isstaged=false, tvars=#T<:Any, func=#<function>, invokes=nothing, next=nothing)julia>jl_(start(methods(sneaky)))Method(sig=Tuple{Array{#T<:Any, N<:Any}, T<:Any}, va=false, isstaged=false, tvars=#T<:Any, func=#<function>, invokes=nothing, next=nothing)

Even though both print as T, in sneaky the second T is not bound, and hence it isn’t constrained to be the same type as the element type of the Array.

Some TypeVar interactions depend on the bound state, even when there are not two or more uses of the same TypeVar. For example:

julia>S=TypeVar(:S,false);T=TypeVar(:T,true)T# These would be the same no matter whether we used S or Tjulia>Array{Array{S}}<:Array{Array}truejulia>Array{Array{S}}<:Array{Array{S}}truejulia>Array{Array}<:Array{Array{S}}true# For these cases, it mattersjulia>Array{Array{Int}}<:Array{Array}falsejulia>Array{Array{Int}}<:Array{Array{S}}falsejulia>Array{Array{Int}}<:Array{Array{T}}true

It’s this latter construction that allows function declarations like

foo{T,N}(A::Array{Array{T,N}})=T,N

to match despite the invariance of Julia’s type parameters.

TypeNames¶

The following two Array types are functionally equivalent, yet print differently via jl_():

julia>TV,NV=TypeVar(:T),TypeVar(:N)(T,N)julia>jl_(Array)Arrayjulia>jl_(Array{TV,NV})Array{T<:Any,N<:Any}

These can be distinguished by examining the name field of the type, which is an object of type TypeName:

julia>xdump(Array.name)TypeNamename:SymbolArraymodule:ModuleCorenames:SimpleVectorlength:Int640primary:Array{T,N}::DataType<:DenseArray{T,N}cache:SimpleVectorlength:Int64135linearcache:SimpleVectorlength:Int6418uid:Int6437

In this case, the relevant field is primary, which holds a reference to the “primary” instance of the type:

julia>pointer_from_objref(Array)Ptr{Void}@0x00007fcc7de64850julia>pointer_from_objref(Array.name.primary)Ptr{Void}@0x00007fcc7de64850julia>pointer_from_objref(Array{TV,NV})Ptr{Void}@0x00007fcc80c4d930julia>pointer_from_objref(Array{TV,NV}.name.primary)Ptr{Void}@0x00007fcc7de64850

The primary field of Array points to itself, but for Array{TV,NV} it points back to the default definition of the type.

What about the other fields? uid assigns a unique integer to each type. To examine the cache field, it’s helpful to pick a type that is less heavily used than Array. Let’s first create our own type:

julia>type MyType{T,N}endjulia>MyType{Int,2}MyType{Int64,2}julia>MyType{Float32,5}MyType{Float32,5}julia>MyType.name.cachesvec(MyType{Float32,5},MyType{Int64,2},Evaluationsucceeded,butanerroroccurredwhileshowingvalueoftype SimpleVector:ERROR:UndefRefError:accesstoundefinedreferenceingetindexat./essentials.jl:211inshow_delim_arrayatshow.jl:229inshowatshow.jl:257inanonymousatshow.jl:1301inwith_output_limitat./show.jl:1278inshowlimitedatshow.jl:1300indisplayatmultimedia.jl:120[inlinedcode]frommultimedia.jl:151indisplayatmultimedia.jl:163

(The error is triggered because the cache is pre-allocated to have length 8, but only the first two entries are populated.) Consequently, when you instantiate a parametric type, each concrete type gets saved in a type-cache. However, instances with TypeVar parameters are not cached.

Tuple-types¶

Tuple-types constitute an interesting special case. For dispatch to work on declarations like x::Tuple, the type has to be able to be able to accommodate any tuple. Let’s check the parameters:

julia>TupleTuplejulia>Tuple.parameterssvec(Vararg{Any})

It’s worth noting that the parameter is a type, Any, rather than a TypeVarT<:Any: compare

julia>jl_(Tuple.parameters)svec(Vararg{Any})julia>jl_(Array.parameters)svec(T<:Any,N<:Any)

Unlike other types, tuple-types are covariant in their parameters, so this definition permits Tuple to match any type of tuple. This is therefore equivalent to having an unbound TypeVar but distinct from a bound TypeVar

julia>typeintersect(Tuple,Tuple{Int,Float64})Tuple{Int64,Float64}julia>typeintersect(Tuple{Vararg{Any}},Tuple{Int,Float64})Tuple{Int64,Float64}julia>T=TypeVar(:T,false)Tjulia>typeintersect(Tuple{Vararg{T}},Tuple{Int,Float64})Tuple{Int64,Float64}julia>T=TypeVar(:T,true)Tjulia>typeintersect(Tuple{Vararg{T}},Tuple{Int,Float64})Union{}

Finally, it’s worth noting that Tuple{} is distinct

julia>Tuple{}Tuple{}julia>Tuple{}.parameterssvec()julia>typeintersect(Tuple{},Tuple{Int})Union{}

What is the “primary” tuple-type?

julia>pointer_from_objref(Tuple)Ptr{Void}@0x00007f5998a04370julia>pointer_from_objref(Tuple{})Ptr{Void}@0x00007f5998a570d0julia>pointer_from_objref(Tuple.name.primary)Ptr{Void}@0x00007f5998a04370julia>pointer_from_objref(Tuple{}.name.primary)Ptr{Void}@0x00007f5998a04370

so Tuple==Tuple{Vararg{Any}} is indeed the primary type.

Introduction to the internal machinery: jltypes.c¶

Many operations for dealing with types are found in the file jltypes.c. A good way to start is to watch type intersection in action. Build Julia with makedebug and fire up Julia within a debugger. gdb debugging tips has some tips which may be useful.

Because the type intersection and matching code is used heavily in the REPL itself—and hence breakpoints in this code get triggered often—it will be easiest if you make the following definition:

julia>function myintersect(a,b)ccall(:jl_breakpoint,Void,(Any,),nothing)typeintersect(a,b)end

and then set a breakpoint in jl_breakpoint. Once this breakpoint gets triggered, you can set breakpoints in other functions.

As a warm-up, try the following:

myintersect(Tuple{Integer,Float64},Tuple{Int,Real})

Set a breakpoint in intersect_tuple and continue until it enters this function. You should be able to see something like this:

Breakpoint2,intersect_tuple(a=0x7ffdf7409150,b=0x7ffdf74091b0,penv=0x7fffffffcc90,eqc=0x7fffffffcc70,var=covariant)atjltypes.c:405405{(gdb)calljl_(a)Tuple{Integer,Float64}(gdb)calljl_(b)Tuple{Int64,Real}

The var argument is either covariant or invariant, the latter being used if you’re matching the type parameters of Array{T1} against Array{T2}. The other two inputs to this function (penv and eqc) may be currently mysterious, but we’ll discuss them in a moment. For now, step through the code until you get into the loop over the different entries in the tuple types a and b. The key call is:

ce=jl_type_intersect(ae,be,penv,eqc,var);

which, if you examine ae, be, and ce, you’ll see is just type intersection performed on these entries.

We can make it more interesting by trying a more complex case:

julia>T=TypeVar(:T,true)Tjulia>myintersect(Tuple{Array{T},T},Tuple{Array{Int,2},Int8})Breakpoint1,jl_breakpoint(v=0x7ffdf35e8010)atbuiltins.c:15591559{(gdb)bintersect_tupleBreakpoint3at0x7ffff6dcb07d:filejltypes.c,line405.(gdb)cContinuing.Breakpoint3,intersect_tuple(a=0x7ffdf74d7a90,b=0x7ffdf74d7af0,penv=0x7fffffffcc90,eqc=0x7fffffffcc70,var=covariant)atjltypes.c:405405{(gdb)calljl_(a)Tuple{Array{＃T<:Any,N<:Any},＃T<:Any}(gdb)calljl_(b)Tuple{Array{Int64,2},Int8}

Let’s watch how this bound TypeVar gets handled. To follow this, you’ll need to examine the variables penv and eqc, which are defined as:

typedefstruct{jl_value_t**data;size_tn;jl_svec_t*tvars;}cenv_t;

These start out empty (with penv->n==eqc->n==0). Once we get into the loop and make the first call to jl_type_intersect, eqc (which stands for “equality constraints”) has the following value:

(gdb)peqc->n$4=2(gdb)calljl_(eqc->data[0])＃T<:Any(gdb)calljl_(eqc->data[1])Int64

This is just a var, value list of pairs, indicating that T now has the value Int64. If you now allow intersect_tuple to finish and keep progressing, you’ll eventually get to type_intersection_matching. This function contains a call to solve_tvar_constraints. Roughly speaking, eqc defines T=Int64, but env defines it as Int8; this conflict is detected in solve_tvar_constraints and the resulting return is jl_bottom_type, aka Union{}.

Subtyping and method sorting¶

Armed with this knowledge, you may find yourself surprised by the following:

julia>typeintersect(Tuple{Array{Int},Float64},Tuple{Array{T},T})Union{}julia>Tuple{Array{Int},Float64}<:Tuple{Array{T},T}true

where T is a bound TypeVar. In other words, A<:B does not imply that typeintersect(A,B)==A. A little bit of digging reveals the reason why: jl_subtype_le does not use the cenv_t constraints that we just saw in typeintersect.

jltypes.c contains three closely related collections of functions for testing how types a and b are ordered:

• The subtype functions implement a<:b. Among other uses, they serve in matching function arguments against method signatures in the function cache.
• The type_morespecific functions are used for imposing a partial order on functions in method tables (from most-to-least specific). Note that jl_type_morespecific(a,b,0) really means “is a at least as specific as b?” and not “is a strictly more specific than b?”
• The type_match functions are similar to type_morespecific, but additionally accept (and employ) an environment to constrain typevars. The related type_match_morespecific functions call type_match with an argument morespecific=1

All three of these take an argument, invariant, which is set to 1 when comparing type parameters and otherwise is 0.

The rules for these are somewhat different. subtype is sensitive to the number arguments, but type_morespecific may not be. In particular, Tuple{Int,AbstractFloat} is more specific than Tuple{Integer}, even though it is not a subtype. (Of Tuple{Int,AbstractFloat} and Tuple{Integer,Float64}, neither is more specific than the other.) Likewise, Tuple{Int,Vararg{Int}} is not a subtype of Tuple{Integer}, but it is considered more specific. However, morespecific does get a bonus for length: in particular, Tuple{Int,Int} is more specific than Tuple{Int,Vararg{Int}}.

If you’re debugging how methods get sorted, it can be convenient to define the function:

args_morespecific(a,b)=ccall(:jl_args_morespecific,Cint,(Any,Any),a,b)

which allows you to test whether arg-tuple a is more specific than arg-tuple b.