I don't really agree that it is a wart. Because the Ranges have such nice
behaviours, I think it is reasonable to let them be the default. People
should be encouraged to use and get familiar with these very elegant data
structures. If (0:N) returned Array{Int, 1}, then that is what everyone
would use. I am just a bit confused as to why 'linrange' was changed to
'linspace'.
I think perhaps the naming of the types are contributing a bit to the
confusion. If what you want is an array of floats, then it seems reasonable
to declare Array{Int,1}, because what can be more natural-sounding? But you
probably don't care whether it's a DenseArray, SparseArray, SubArray, Range
or whatever. It's just that 'Array' sounds incredibly general. It's a bit
odd to me that Array is a subtype of DenseArray, and not the other way
around.
'AbstractArray' on the other hand, sounds kind of obscure and spooky. I
think the mental hurdle would be lower if AbstractArray was called 'Array'.
(I also find that 'String' sounds more general than 'AbstractString'...)
As for the performance of abstract types, I am a bit on thin ice, but I
think what you want to avoid is to have an Array with mixed concrete
element types. There is no problem with writing your functions for any
subtype of an abstract array type as such, as long as the instances of that
type have elements of a single concrete type.
On Wednesday, October 21, 2015 at 8:52:20 PM UTC+2, Gabriel Gellner wrote:
>
> Oh man thanks for this link. Makes me feel better that I am not alone in
> feeling this pain. This is really the first *wart* I have felt in the
> language decisions in Julia. Forcing iterators as the default such a common
> array generation object feels so needless. Calling any code that asks for a
> concrete array instead of a AbstractArray also feels dangerous...
> especially when at first approximation almost all the builtin basic array
> generation functions returns concrete arrays.
>
