Right, the question is essentially whether you can implicitly introduce
type parameters for the programmer – which you can for immutable types but
not for mutable types. This example may make the difference clearer:
type Foo1
field::Number
end
type Foo2{T<:Number}
field::T
end
These types are pretty similar, but there's an important behavioral
difference:
julia> foo1 = Foo1(123)
Foo1(123)
julia> foo2 = Foo2(123)
Foo2{Int64}(123)
julia> foo1.field = 1.23
1.23
julia> foo1
Foo1(1.23)
julia> foo2.field = 1.23
ERROR: InexactError()
in convert at int.jl:185
Since the type of `.field` is encoded in the type of Foo2, you can change
the value of `.field` but not it's type. For Foo1, you can change the value
and the type of `.field.` Thus, if you have code that's specialized for a
particular kind of Foo2, it is specialized for the type of `.field` as well
– and in particular, that type cannot change over the course of the
function. If you've got code that's specialized for Foo1, you don't know
anything about the type of `.field` and moreover that type can change
through the course of a single function body. For immutables, of course,
the value of a field can't change, nevermind its type, so you could
implicitly make the type of any field part of the type.
On Wed, Oct 22, 2014 at 12:30 PM, John Myles White <johnmyleswh...@gmail.com
> wrote:
> The clean way to get that effect is via parametric types.
>
> -- John
>
> On Oct 22, 2014, at 9:08 AM, Cedric St-Jean <cedric.stjean...@gmail.com>
> wrote:
>
> Somewhat OT: since the JIT compiles a different function for each argument
> type combination, couldn't it compile a different type object for every
> field type combination?
>
> On Wednesday, October 22, 2014 10:53:26 AM UTC-4, Iain Dunning wrote:
>>
>> Do you feel like you are over-typing things?
>>
>> In function definitions, you only need types if you actually need to them
>> to pick a function to dispatch to. They don't make anything go faster, as a
>> specific version of a function will be compiled for every different set of
>> argument types you try calling it with.
>>
>> So, check out:
>> https://github.com/IainNZ/GraphLayout.jl/blob/master/src/spring.jl
>> for example.
>> layout_spring_adj{T}(adj_matrix::Array{T,2}
>> So it takes any array of element type T. For every time you call this
>> with a different element type, a different version of the function will be
>> compiled. So this fancy looking code:
>> if adj_matrix[i,j] != zero(eltype(adj_matrix))
>> Simply gets turned into if adj_matrix[i,j] != 0.0 or 0 or False or ....
>> and so on, pretty magic!
>>
>> For Types, you should specify concrete types whenever you can, or use
>> parametric types if you can't. If you don't, and use say, Number, or leave
>> it blank, simple things like Float64s and Ints will be "boxed", so there
>> will be overhead whenever you use them and the compiler may struggle to
>> infer that some things are Float64s or Ints and not just Anys.
>>
>> Hope that helps somewhat.
>>
>> On Wednesday, October 22, 2014 7:28:12 AM UTC-4, Nils Gudat wrote:
>>>
>>> Hi Andreas,
>>>
>>> Don't know if you've seen this already and whether this is helpful at
>>> all, but I discovered this site
>>> <http://sidekick.windforwings.com/2013/03/print-julia-type-tree-with-juliatypesjl.html>
>>> once when I got confused by some TypeErrors, it basically lays out the
>>> entire type tree of Julia.
>>>
>>> Best,
>>> Nils
>>>
>>> On Wednesday, October 22, 2014 12:11:03 PM UTC+1, Andreas Lobinger wrote:
>>>>
>>>> Hello,
>>>>
>>>> i'm now a julia user for some time, but still i have problems (comming
>>>> from a c, f77, matlab, python background) to understand the type system.
>>>> Especially when i try to integrate own code into packages (happened to
>>>> Cairo + Compose, pending for Winston) i seem to choose always a more
>>>> complicated way (my observation, code similar in py or c just looks
>>>> shorter...) because somehow things do not match.
>>>>
>>>> So.
>>>>
>>>> What to read to understand the julia approach to types and type
>>>> interference?
>>>>
>>>> Wishing a happy day,
>>>> Andreas
>>>>
>>>>
>>>>
>
