Perhaps the Julian curly-brace array syntax makes Any[] arrays seem special
(especially to Matlab converts), when they're really not all that
different. Yes, users need to learn that Array{Real} is not a supertype of
Array{Int}. But that's a common theme throughout Julia's type system, and
really needs to be learned as soon as learning about parametric types. I
think the manual does a good job here — Parametric
Types<http://docs.julialang.org/en/latest/manual/types/#man-parametric-types>.
Is there a way that it could be written more clearly?
On Tuesday, April 29, 2014 12:39:28 PM UTC-4, Stefan Karpinski wrote:
>
> On Tue, Apr 29, 2014 at 12:13 PM, Oliver Woodford
> <[email protected]<javascript:>
> > wrote:
>
>> Quick question, folks:
>>
>> Does f(x::Array{Union(Int8,Int16)}) mean that x must be all Int8 or all
>> Int16 (homogenous), or each element can be either Int8 or Int16
>> (heterogeneous)?
>>
>> If the latter, then would I need to
>> use f(x::Union(Array{Int8},Array{Int16})) to achieve the former?
>>
>
> Yes and yes.
>
>
>> If so, then what I am suggesting is having two array types, Array and
>> Cell, and have f(x::Array{Union(Int8,Int16)}) be equivalent to the
>> current f(x::Union(Array{Int8},Array{Int16})), and have
>> f(x::Cell{Union(Int8,Int16)}) be equivalent to the current
>> f(x::Array{Union(Int8,Int16)}).
>>
>
> This is not a minor change. What you're asking for is having both
> invariant and covariant parametric types in the language – Array would be
> covariant and Cell would be invariant. If you're going to have invariant
> and covariant type parameters, you'll want contravariant type parameters
> too. At that point, you need to have a way of annotating the variance of a
> type's parameters – and worse still, you have to explain all this to
> everyone. At that point, you have Scala and all the
> complications<http://blogs.atlassian.com/2013/01/covariance-and-contravariance-in-scala/>and
>
> questions<http://stackoverflow.com/questions/4531455/whats-the-difference-between-ab-and-b-in-scala>that
> come with that. I don't think that's the right path for a language
> that's meant to be used by people who are scientists rather than
> professional programmers (honestly, I don't really think it's a good idea
> for professional programmers either). Making all parametric types covariant
> is a more reasonable possibility, but as I pointed out, it has its own
> significant issues.
>
