On Tuesday, April 29, 2014 9:29:56 AM UTC-7, Oliver Woodford wrote: > > On Tuesday, April 29, 2014 5:14:01 PM UTC+1, Jason Merrill wrote: >> >> Suppose the types that you want existed. Let's call them ConcreteArray, >> and Cell. >> >> ConcreteArray gives the guarantee that all of it's elements are stored >> directly with a fixed stride. >> >> Can you give some examples of functions that would use these in their >> type signature? >> > Sure. sum(x::ConcreteArray{Number}). Because currently if I write > sum(x::Array{Real}) and try to pass in an Array{Float64} I get an error. > > Note that most arrays are actually homogeneous (as Jacob and Matt both > stated), so if you want to make sure of that you need to use static > parameters. I'm suggesting a system that doesn't require static parameters > for the usual case. >
Take a look at the actual implementations of sum in reduce.jl: https://github.com/JuliaLang/julia/blob/master/base/reduce.jl#L179 https://github.com/JuliaLang/julia/blob/master/base/reduce.jl#L275 Julia often has method definitions that are significantly more generic than sum(x::ConcreteArray{Number}), which I think is really nice. The definitions above are fast for Array{Float64}, but the very same definitions also work for e.g. an array of matrices, or anything else with + defined (zero(T) might have to be defined too if the array is empty or has only 1 element). I don't see much advantage of having an implementation like sum(x::ConcreteArray{Number}) if someone later comes along and defines sum(x::AbstractArray) with essentially the same body.