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.
