Yup. Maybe another way to say it: the function system can do so much ad hoc
specialization precisely because the type system provides enough invariants for
the compiler to depend upon.
-- John
On Oct 22, 2014, at 9:37 AM, Stefan Karpinski <ste...@karpinski.org> wrote:
> 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 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
>>
>>
>
>
